+++ /dev/null
-.pl 10.0i
-.po 0
-.ll 7.2i
-.lt 7.2i
-.nr LL 7.2i
-.nr LT 7.2i
-.ds LF Riikonen
-.ds RF FORMFEED[Page %]
-.ds CF
-.ds LH Internet Draft
-.ds RH 2 February 2004
-.ds CH
-.na
-.hy 0
-.in 0
-.nf
-Network Working Group P. Riikonen
-Internet-Draft
-draft-riikonen-presence-attrs-03.txt 2 February 2004
-Expires: 2 August 2004
-
-.in 3
-
-.ce 2
-User Online Presence and Information Attributes
-<draft-riikonen-presence-attrs-03.txt>
-
-.ti 0
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with
-all provisions of Section 10 of RFC 2026. Internet-Drafts are
-working documents of the Internet Engineering Task Force (IETF), its
-areas, and its working groups. Note that other groups may also
-distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-The distribution of this memo is unlimited.
-
-
-.ti 0
-Abstract
-
-This document defines set of attributes that can represent the online
-user's presence in a network, and to provide general information about
-the user. The purpose is to provide a generic mechanism to share
-online presence and status, and general information about the user
-to be used in several kind of network protocols and applications.
-These attributes could be used by for example chat and conferencing
-protocols (such as Instant Message protocols), network games, and
-other similar network protocols and applications that has online
-users in a network.
-
-
-
-
-
-
-
-.ti 0
-Table of Contents
-
-.nf
-1 Introduction .................................................. 2
- 1.1 Requirements Terminology .................................. 2
-2 Attributes Concept ............................................ 3
- 2.1 Requesting Attributes ..................................... 3
- 2.2 Replying Attributes ....................................... 3
- 2.3 Attribute Data Types ...................................... 4
- 2.4 Attribute Payload ......................................... 4
- 2.5 Attributes ................................................ 5
-3 Security Considerations ....................................... 11
-4 References .................................................... 12
-5 Author's Address .............................................. 13
-6 Full Copyright Statement ...................................... 13
-
-
-.ti 0
-1. Introduction
-
-This document defines set of attributes that can represent the online
-user's presence in a network, and to provide general information about
-the user. The purpose is to provide a generic mechanism to share
-online presence and status, and general information about the user
-to be used in several kind of network protocols and applications.
-These attributes could be used by for example chat and conferencing
-protocols (such as Instant Message protocols), network games, and
-other similar network protocols and applications that has online
-users in a network.
-
-This document does not define these attributes to be used in any
-specific protocol, but assumes that they can be used generally in
-any kind of online network protocol. Furthermore, the document
-pays attention to special needs of various protocols, such as
-mobile network protocols, which requires the attributes to be
-both robust and compact. The attributes are also considered to be
-easily implementable and for this reason a clear and robust structure
-was chosen for the attributes.
-
-This document is strongly influenced by Wireless Village Initiative
-where similar attributes are defined, and credits for the ideas are
-due there. However, they are defined only in the context of the
-Wireless Village, and the format of the attributes used is not
-suitable for general purpose usage.
-
-
-.ti 0
-1.1 Requirements Terminology
-
-The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
-MAY, and OPTIONAL, when they appear in this document, are to be
-interpreted as described in [RFC2119].
-
-
-.ti 0
-2 Attributes Concept
-
-Many network protocols needs a way to transfer and retrieve status
-information about users in a network. For example, many chat and
-conferencing protocols such as IRC, and all Instant Message (IM)
-protocols, such as ICQ has a way to retrieve presence and status
-information about the users in the network. This could be added to
-several other kind of network protocols as well, and for this reason
-a defined mechanism to provide these informations is needed.
-
-The attributes are usually requested by an entity in the network
-from other entity, usually a user or end user's device in the network.
-The recipient then replies to each of the requested attributes and
-sends the reply to the requester.
-
-This document does not define the actual transport for requesting and
-providing the replies to the requests, since this is irrelevant.
-This document defines a payload for requesting, and providing the
-information, but how the payload is transported is not defined in
-this document. In a client-server network model the user requesting
-attributes usually destine the request to a remote user and the
-server relays the attributes to the remote user. It is also possible
-that the concept is not user-to-user, but the server replies to the
-requested attributes on behalf of the user.
-
-
-.ti 0
-2.1 Requesting Attributes
-
-When an entity requests attributes from a user in the network,
-it assembles a list of Attribute Payloads, and sets the requested
-attribute value into the payload. Each requested attribute is a separate
-Attribute Payload and they MUST be appended one after the other. The
-requester need to understand that the recipient may not understand all
-the requested attributes, and may not reply to all of the requested
-attributes. The requester also need to understand that the recipient
-may reply with additional attributes that were not requested.
-
-
-.ti 0
-2.2 Replying Attributes
-
-When en entity receives the Attribute Payloads it parses them one after
-the other. The entity can parse each of the Attribute Payload separately
-since it knows the length of the current attribute; next attribute
-begins after the current attribute ends. The entity then checks the
-requested attribute and SHOULD reply either with valid value or with
-an indication that the attribute is unsupported or unknown. It is
-also possible to reply with additional attributes that were not
-requested.
-
-When replying to the requested attributes the entity assembles a list
-of Attribute Payloads, each including the attribute type and the
-actual attribute data.
-
-
-.ti 0
-2.3 Attribute Data Types
-
-This section defines basic data types that can appear in the attributes
-in this document.
-
-All integer values are stored in the MSB first order. The size of the
-integer is provided separately with the attribute. Integer is
-represented as "integer" in this documentation.
-
-Strings MUST be UTF-8 [RFC2279] encoded, and include 2 bytes length
-field indicating the length of the string. Hence, when "string" value
-appears in this documentation it is encoded as:
-
-.in 6
-Length Type Value
-2 bytes integer Length of String field
-variable UTF-8 String
-.in 3
-
-If string is not present then the length field includes zero (0)
-value.
-
-Boolean value is represented as "boolean" and its size is 1 byte.
-Value 0x00 indicates false value and value 0x01 indicates true value.
-
-
-.ti 0
-2.4 Attribute Payload
-
-The Attribute Payload is used to request an attribute, and to reply
-to the requested attribute. One payload includes one attribute.
-
-
-.in 5
-.nf
- 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Attribute | Attr Flags | Attribute Length |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| |
-~ Attribute Data ~
-| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-.in 3
-
-.ce
-Figure 1: Attribute Payload
-
-
-.in 6
-o Attribute (1 byte) - Indicates the attribute included in this
- Attribute Payload.
-
-o Attribute Flags (1 byte) - Indicates the flags associated
- with this attribute. The following flags are defined:
-
- 0x01 ATTRIBUTE_FLAG_INVALID
-
- The attribute value in Attribute Data is invalid, or
- unknown. This may be set to indicate that a requested
- attribute is not available, its value is unknown, or
- sender does not understand it.
-
- 0x02 ATTRIBUTE_FLAG_VALID
-
- The attribute value is included in the Attribute Data.
-
- When sending this payload to request attributes this value
- MUST be set to zero (0) value. When sending a reply to the
- request this field MUST NOT include a zero (0) value.
-
-o Attribute Length (2 bytes) - Indicates the length of the
- Attribute Data field, not including any other field.
-
-o Attribute Data (variable length) - The Attribute Data.
- The contents of this field is attribute specific, defined
- subsequently.
-.in 3
-
-
-.ti 0
-2.5 Attributes
-
-The following values can appear in the Attribute field in the
-Attribute Payload to indicate the content of the attribute. The
-format of the attribute data is represented as length, type and
-value. Example:
-
-.in 6
-Length Type Value
-2 bytes integer Some integer value
-variable string Some string
-1 byte boolean Boolean value
-.in 3
-
-When sending multiple Attribute Payloads it is possible to include
-multiple same attributes in the packet.
-
-
-.in 6
-0 ATTRIBUTE_NONE
-
- This attribute is reserved and it is never sent.
-
-
-1 ATTRIBUTE_USER_INFO
-
- This attribute includes general information about the user, their
- name and contact information. The content of this attribute is
- a VCard version 3.0 as defined in RFC 2426 [RFC2426] and RFC 2425
- [RFC2425]. Note that some of the information that VCard provides
- can be also provided in the means of providing other attributes.
- The rationale for this is that the VCard does not provide all the
- information, or with the required precision that may be desired in
- some applications. It is therefore RECOMMENDED that this attribute
- would be used to provide only basic and constant user information,
- such as name and contact information, but not online status
- information.
-
- Length Type Value
- variable VCard Basic user information
-
-
-2 ATTRIBUTE_SERVICE
-
- This attribute indicates a service in the Internet that the user
- is currently using or has logged in. It also shows when the user
- started using the service, and how long user has been idle in the
- service. The value of this attribute is as follows:
-
- Length Type Value
- 4 bytes integer Service Port (IANA specified)
- variable string Service Address
- 1 byte boolean Online status. If this is set to
- 0x01 (true) it means the user is online
- in the service. Set to 0x00 (false) when
- out of reach.
- variable string Signon date and time, UTC date, format as
- in ISO 8601
- 4 bytes integer Idle time
-
-
-3 ATTRIBUTE_STATUS_MOOD
-
- This attribute indicates the mood of the user. It can indicate
- whether the user is eager to participate in the network. The
- value of this attribute is as follows:
-
- Length Type Value
- 4 bytes integer Mood mask (values ORed together)
-
- The following mood values are defined:
-
- 0x00000000 MOOD_NORMAL No specific mood, normal mood
- 0x00000001 MOOD_HAPPY The user feels happy
- 0x00000002 MOOD_SAD The user feels sad
- 0x00000004 MOOD_ANGRY The user feels angry
- 0x00000008 MOOD_JEALOUS The user feels jealous
- 0x00000010 MOOD_ASHAMED The user feels ashamed
- 0x00000020 MOOD_INVINCIBLE The user feels invincible
- 0x00000040 MOOD_INLOVE The user feels being in love
- 0x00000080 MOOD_SLEEPY The user feels sleepy
- 0x00000100 MOOD_BORED The user feels bored
- 0x00000200 MOOD_EXCITED The user feels excited
- 0x00000400 MOOD_ANXIOUS The user feels anxious
-
-
-4 ATTRIBUTE_STATUS_FREETEXT
-
- This attribute includes the user's online status free text. It
- can provide personal status as a text message. The contents of
- this attribute is a UTF-8 encoded free text string.
-
- Length Type Value
- variable string Free text status string
-
-
-5 ATTRIBUTE_STATUS_MESSAGE
-
- This attribute includes the user's online status message. It
- could provide for example a multi media message showing the status
- of the user. The contents of this attribute is a MIME object,
- which can be used to provide for example video, audio, image or
- other similar status message. It could also provide a reference
- to the message, for example an URL address.
-
- Length Type Value
- variable MIME Status message as MIME object
-
-
-6 ATTRIBUTE_PREFERRED_LANGUAGE
-
- This attribute indicates the preferred language to be used when
- communicating. The encoding of this attribute is as follows:
-
- Length Type Value
- variable string ISO 639-2/T three letter code
-
-
-7 ATTRIBUTE_PREFERRED_CONTACT
-
- This attribute indicates the preferred contact methods. It can
- indicate the method the user prefers when contacting. The value
- of this attribute is as follows:
-
- Length Type Value
- 4 bytes integer Contact mask (values ORed together)
-
- The following contact methods are defined:
-
- 0x00000000 CONTACT_NONE No specific preferred contact method
- 0x00000001 CONTACT_EMAIL Email is preferred
- 0x00000002 CONTACT_CALL Phone call is preferred
- 0x00000004 CONTACT_PAGE Paging is preferred
- 0x00000008 CONTACT_SMS SMS is preferred
- 0x00000010 CONTACT_MMS MMS is preferred
- 0x00000020 CONTACT_CHAT Chatting is preferred
- 0x00000040 CONTACT_VIDEO Video conferencing is preferred
-
-
-8 ATTRIBUTE_TIMEZONE
-
- This attribute can be used to provide the current local time for
- the user. The contents of this attribute is a UTF-8 encoded
- string and the format of the string is UTC time zone defined
- in the ISO 8601.
-
- Length Type Value
- variable string UTC date, format as in ISO 8601
-
- Note that ATTRIBUTE_USER_INFO may also provide this information.
- However it is RECOMMENDED that this attribute is used when
- current time zone information is provided.
-
-
-9 ATTRIBUTE_GEOLOCATION
-
- This attribute can be used to provide measured global location of
- the user. How this information is gathered is out of scope of
- this document. The attribute can provide latitude and longitude
- lateral positions, but also a vertical position. A parameter
- describing the accuracy of the information can also be provided.
-
- Length Type Value
- variable string Longitude (ex. 31 17 14.321W)
- variable string Latitude (ex. 12 11 21.2N)
- variable string Altitude
- variable string Accuracy in meters
-
- Note that ATTRIBUTE_USER_INFO may also provide this information,
- however it does not have the vertical position, or the accuracy
- parameter. It is RECOMMENDED that this attribute is used when
- providing current global position information.
-
-
-10 ATTRIBUTE_DEVICE_INFO
-
- This attribute includes information about the user's device.
- The encoding of this attribute is as follows:
-
- Length Type Value
- 4 bytes integer Device type
- variable string Name of the device manufacturer
- variable string Device version
- variable string Device model
- variable string Device language (ISO 639-2/T)
-
- The following Device types are defined:
-
- 0 DEVICE_COMPUTER Device is a computer
- 1 DEVICE_MOBILE_PHONE Device is a mobile phone
- 2 DEVICE_PDA Device is a PDA
- 3 DEVICE_TERMINAL Device is a terminal
-
-
-11 ATTRIBUTE_EXTENSION
-
- This attribute indicates that the attribute value is vendor,
- application or service specific attribute extension. This field
- MUST include a MIME object, which is the extension value. This
- document does not specify any explicit MIME objects for this
- attribute.
-
- Length Type Value
- variable MIME Attribute extension as MIME object
-
-
-12 ATTRIBUTE_USER_PUBLIC_KEY
-
- This attribute includes the user's public key or certificate.
- As the public key and certificate format depends on which sort
- of algorithm or certificate encoding user is using we need to
- define a mechanism to differentiate the public key types from
- each other. This document specifies the most common public keys
- and certificates. This attribute can be used to deliver the
- user's public key, and it MUST be present if also the
- ATTRIBUTE_USER_DIGITAL_SIGNATURE is present. Note that the
- recipient of this attribute SHOULD verify the public key from
- a third party, for example from Certification Authority. If
- there are more than one ATTRIBUTE_USER_PUBLIC_KEY attributes set
- and ATTRIBUTE_USER_DIGITAL_SIGNATURE is also set, the digital
- signature SHOULD be verifiable with the first set public key.
-
- Length Type Value
- variable string Public key/certificate type
- variable data Public key/certificate data
-
- The following public key/certificate types are defined:
-
- ssh-rsa SSH RSA public key [SSH-TRANS]
- ssh-dss SSH DSS public key [SSH-TRANS]
- silc-rsa SILC RSA public key [SILC1]
- silc-dss SILC DSS public key [SILC1]
- pgp-sign-rsa OpenPGP RSA certificate [RFC2440]
- pgp-sign-dss OpenPGP DSS certificate [RFC2440]
- x509v3-sign-rsa X.509 Version 3 RSA certificate [RFC2459]
- x509v3-sign-dss X.509 Version 3 DSS certificate [RFC2459]
-
- Most of these public key/certificate types are equivalent to
- the types specified for SSH protocol [SSH-TRANS] and are expected
- to be officially assigned by IANA.
-
- The encoding of the public key/certificate data in the attribute
- is done in the manner defined in their respective definitions.
-
- Note that these public keys are intended for signing. Some
- certificates may have a key usage restrictions and same key cannot
- be used for both encryption and signing. Therefore, the name
- of the certificate type indicates if they are intended for
- signing only.
-
-
-13 ATTRIBUTE_SERVER_PUBLIC_KEY
-
- This attribute includes a third party server or authority public
- key or CA certificate and MUST be present if the attribute
- ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also present. The format
- for this attribute is identical to the ATTRIBUTE_USER_PUBLIC_KEY
- attribute. If there are more than one ATTRIBUTE_SERVER_PUBLIC_KEY
- attributes set and ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also set,
- the digital signature SHOULD be verifiable with the first set public
- key.
-
-
-14 ATTRIBUTE_USER_DIGITAL_SIGNATURE
-
- This attribute value includes digital signature of all Attribute
- Payloads except this attribute. This signature can be provided by
- the user. This attribute SHOULD be last attribute provided in the
- reply so that it is easier for the receiver to compute the signature
- data to be verified. The format and encoding of this attribute
- depends on the public key or certificate used to produce the
- signature. See the ATTRIBUTE_USER_PUBLIC_KEY for all public keys
- and certificates that can be used to produce a signature.
-
- Length Type Value
- variable data Digital signature data
-
- The encodings are as follows per public key/certificate type:
-
- ssh-rsa and ssh-dss Defined in [SSH-TRANS]
- silc-rsa and silc-dss Defined in [SILC1]
- pgp-sign-rsa and pgp-sign-dss Defined in [RFC2440]
- x509v3-sign-rsa and x509v3-sign-dss Defined in [PKCS7]
-
- The procedure producing the signature and encoding it are done
- in the manner defined in their respective definitions, see the
- provided references. Also the hash function used with the
- signature procedure is defined by the public key/certificate type.
-
-
-15 ATTRIBUTE_SERVER_DIGITAL_SIGNATURE
-
- This attribute value includes digital signature of all Attribute
- Payloads except this attribute, but including the attribute
- ATTRIBUTE_USER_DIGITAL_SIGNATURE. This signature can be provided
- by a third party server or an authority which has verified the
- information provided by the user. How it verifies this information
- is out of scope of this document, however it may base its
- information to a previous registration information and current
- online status of the user in a service. This attribute SHOULD be
- last when provided, so that it is easier for the receiver to
- compute the signature data to be verified. The format for this
- attribute is identical to the ATTRIBUTE_USER_DIGITAL_SIGNATURE
- attribute.
-.in 3
-
-
-.ti 0
-3 Security Considerations
-
-The use of these attributes dictates whether the attributes need to
-be secured or not. However, as the attributes are considered to provide
-accurate status information about specific user, it is suggested that
-the attributes would be secured. The attributes should be digitally
-signed whenever it is possible. Attributes can also be encrypted
-if it is provided by the protocol using the attributes. A third party,
-like a server in the network, could also verify the information and provide
-digital signature in case the information is accurate.
-
-Even though the attributes would be digitally signed by the sender of
-the attributes, the information contained in the attribute may still
-be incorrect. The third party server should not apply digital signature
-unless it can verify every attribute. The receiver of the attributes
-should also not trust that the information in fact is correct.
-
-However, it is possible that the context where these attributes are used
-the attributes are provided by a party that can provide the accurate
-information. For example a server in the network could reply to the
-attributes on behalf of the actual user for some of the attributes.
-
-
-.ti 0
-4 References
-
-[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
-
-[RFC2425] Howes, T., et al, "A MIME Content-Type for Directory
- Information", RFC 2425, September 1998.
-
-[RFC2426] Dawson, F., et al, "vCard MIME Directory Profile",
- RFC 2426, September 1998.
-
-[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
- Protocol Specification", Internet Draft, May 2002.
-
-[RFC2440] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
- November 1998.
-
-[RFC2459] Housley, R., et al, "Internet X.509 Public Key
- Infrastructure, Certificate and CRL Profile", RFC 2459,
- January 1999.
-
-[SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
- Internet Draft.
-
-[PKCS7] Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
- Version 1.5", RFC 2315, March 1998.
-
-
-
-
-.ti 0
-5 Author's Address
-
-Pekka Riikonen
-Snellmaninkatu 34 A 15
-70100 Kuopio
-Finland
-
-EMail: priikone@iki.fi
-
-
-.ti 0
-6 Full Copyright Statement
-
-Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it
-or assist in its implementation may be prepared, copied, published
-and distributed, in whole or in part, without restriction of any
-kind, provided that the above copyright notice and this paragraph are
-included on all such copies and derivative works. However, this
-document itself may not be modified in any way, such as by removing
-the copyright notice or references to the Internet Society or other
-Internet organizations, except as needed for the purpose of
-developing Internet standards in which case the procedures for
-copyrights defined in the Internet Standards process must be
-followed, or as required to translate it into languages other than
-English.
-
-The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-This document and the information contained herein is provided on an
-"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
projects / runtime.git / blobdiff