Network Working Group P. Riikonen Internet-Draft draft-riikonen-presence-attrs-01.txt 25 November 2002 Expires: 25 April 2003 User Online Presence and Information Attributes 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. 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. Riikonen [Page 1] Internet Draft 25 November 2002 Table of Contents 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 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. 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]. Riikonen [Page 2] Internet Draft 25 November 2002 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. 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. 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. Riikonen [Page 3] Internet Draft 25 November 2002 When replying to the requested attributes the entity assembles a list of Attribute Payloads, each including the attribute type and the actual attribute data. 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 are always 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: Length Type Value 2 bytes integer Length of String field variable UTF-8 String 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. 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. 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Attribute Payload Riikonen [Page 4] Internet Draft 25 November 2002 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. 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: Length Type Value 2 bytes integer Some integer value variable string Some string 1 byte boolean Boolean value When sending multiple Attribute Payloads it is possible to include multiple same attributes in the packet. 0 ATTRIBUTE_NONE This attribute is reserved and it is never sent. Riikonen [Page 5] Internet Draft 25 November 2002 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: Riikonen [Page 6] Internet Draft 25 November 2002 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 Riikonen [Page 7] Internet Draft 25 November 2002 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 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, Riikonen [Page 8] Internet Draft 25 November 2002 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 Riikonen [Page 9] Internet Draft 25 November 2002 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 Riikonen [Page 10] Internet Draft 25 November 2002 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. 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 Riikonen [Page 11] Internet Draft 25 November 2002 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. 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. Riikonen [Page 12] Internet Draft 25 November 2002 5 Author's Address Pekka Riikonen Snellmaninkatu 34 A 15 70100 Kuopio Finland EMail: priikone@iki.fi This Internet-Draft expires 25 April 2003 Riikonen [Page 13]