8 .ds RF FORMFEED[Page %]
17 Network Working Group P. Riikonen
19 draft-riikonen-presence-attrs-00.txt 15 May 2002
20 Expires: 15 November 2002
25 User Online Presence and Information Attributes
26 <draft-riikonen-presence-attrs-00.txt>
31 This document is an Internet-Draft and is in full conformance with
32 all provisions of Section 10 of RFC 2026. Internet-Drafts are
33 working documents of the Internet Engineering Task Force (IETF), its
34 areas, and its working groups. Note that other groups may also
35 distribute working documents as Internet-Drafts.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 The list of current Internet-Drafts can be accessed at
43 http://www.ietf.org/ietf/1id-abstracts.txt
45 The list of Internet-Draft Shadow Directories can be accessed at
46 http://www.ietf.org/shadow.html
48 The distribution of this memo is unlimited.
54 This document defines set of attributes that can represent the online
55 user's presence in a network, and to provide general information about
56 the user. The purpose is to provide a generic mechanism to share
57 online presence and status, and general information about the user
58 to be used in several kind of network protocols and applications.
59 These attributes could be used by for example chat and conferencing
60 protocols (such as Instant Message protocols), network games, and
61 other similar network protocols and applications that has online
74 1 Introduction .................................................. x
75 1.1 Requirements Terminology .................................. x
76 2 Attributes Concept ............................................ x
77 2.1 Requesting Attributes ..................................... x
78 2.2 Replying Attributes ....................................... x
79 2.3 Attribute Data Types ...................................... x
80 2.4 Attribute Payload ......................................... x
81 2.5 Attributes ................................................ x
82 3 Security Considerations ....................................... x
83 4 References .................................................... x
84 5 Author's Address .............................................. x
90 This document defines set of attributes that can represent the online
91 user's presence in a network, and to provide general information about
92 the user. The purpose is to provide a generic mechanism to share
93 online presence and status, and general information about the user
94 to be used in several kind of network protocols and applications.
95 These attributes could be used by for example chat and conferencing
96 protocols (such as Instant Message protocols), network games, and
97 other similar network protocols and applications that has online
100 This document does not define these attributes to be used in any
101 specific protocol, but assumes that they can be used generally in
102 any kind of online network protocol. Furthermore, the document
103 pays attention to special needs of various protocols, such as
104 mobile network protocols, which requires the attributes to be
105 both robust and compact. The attributes are also considered to be
106 easily implementable and for this reason a clear and robust structure
107 was chosen for the attributes.
109 This document is strongly influenced by Wireless Village Initiative
110 where similar attributes are defined. However, they are defined
111 only in the context of the Wireless Village, and the format of the
112 attributes used is not suitable for general purpose usage.
116 1.1 Requirements Terminology
118 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
119 MAY, and OPTIONAL, when they appear in this document, are to be
120 interpreted as described in [RFC2119].
126 Many network protocols needs a way to transfer and retrieve status
127 information about users in a network. For example, many chat and
128 conferencing protocols such as IRC, and all Instant Message (IM)
129 protocols, such as ICQ has a way to retrieve presence and status
130 information about the users in the network. This could be added to
131 several other kind of network protocols as well, and for this reason
132 a defined mechanism to provide these informations is needed.
134 The attributes are usually requested by an entity in the network
135 from other entity, usually a user or end user's device in the network.
136 The recipient then replies to each of the requested attributes and
137 sends the reply to the requester.
139 This document does not define the actual transport for requesting and
140 providing the replies to the requests, since this is irrelevant.
141 This document defines a payload for requesting, and providing the
142 information, but how the payload is transported is not defined in
143 this document. In a client-server network model the user requesting
144 attributes usually destines the request to a remote user and the
145 server relays the attributes to the remote user.
149 2.1 Requesting Attributes
151 When an entity requests attributes from a user in the network,
152 it assembles a list of Attribute Payloads, and sets the requested
153 attribute value into the payload. Each requested attribute is a separate
154 Attribute Payload and they MUST be appended one after the other. The
155 requester need to understand that the recipient may not understand all
156 the requested attributes, and may not reply to all of the requested
157 attributes. The requester also need to understand that the recipient
158 may reply with additional attributes that were not requested.
162 2.2 Replying Attributes
164 When user receives the Attribute Payloads it parses them one after
165 the other. The user can parse each of the Attribute Payload separately
166 since it knows the length of the current attribute; next attribute
167 begins after the current attribute ends. The user then checks the
168 requested attribute and SHOULD reply either with valid value or with
169 an indication that the attribute is unsupported or unknown. It is
170 also possible to reply with additional attributes that were not
173 When replying to the requested attributes the user assembles a list
174 of Attribute Payloads, each including the attribute type and the
175 actual attribute data.
179 2.3 Attribute Data Types
181 This section defines basic data types that can appear in the attributes
184 All integer values are stored in the MSB first order. The size of the
185 integer is provided separately with the attribute. Integer is
186 represented as "integer" in this documentation.
188 Strings are always UTF-8 [RFC2279] encoded, and include 2 bytes length
189 field indicating the length of the string. Hence, when "string" value
190 appears in this documentation it is encoded as:
194 2 bytes integer Length of String field
195 variable UTF-8 String
198 If string is not present then the length field includes zero (0)
201 Boolean value is represented as "boolean" and its size is 1 byte.
202 Value 0x00 indicates false value and value 0x01 indicates true value.
206 2.4 Attribute Payload
208 The Attribute Payload is used to request an attribute, and to reply
209 to the requested attribute. One payload includes one attribute.
215 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
216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
217 | Attribute | Attr Flags | Attribute Length |
218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
226 Figure 1: Attribute Payload
230 o Attribute (1 byte) - Indicates the attribute included in this
233 o Attribute Flags (1 byte) - Indicates the flags associated
234 with this attribute. The following flags are defined:
236 0x01 ATTRIBUTE_FLAG_INVALID
238 The attribute value in Attribute Data is invalid, or
239 unknown. This may be set to indicate that a requested
240 attribute is not available, its value is unknown, or
241 sender does not understand it.
243 0x02 ATTRIBUTE_FLAG_VALID
245 The attribute value is included in the Attribute Data.
247 When sending this payload to request attributes this value
248 MUST be set to zero (0) value. When sending a reply to the
249 request this field MUST NOT include a zero (0) value.
251 o Attribute Length (2 bytes) - Indicates the length of the
252 Attribute Data field, not including any other field.
254 o Attribute Data (variable length) - The Attribute Data.
255 The contents of this field is attribute specific, defined
262 The following values can appear in the Attribute field in the
263 Attribute Payload to indicate the content of the attribute. The
264 format of the attribute data is represented as length, type and
269 2 bytes integer Some integer value
270 variable string Some string
271 1 byte boolean Boolean value
274 When sending multiple Attribute Payloads it is possible to include
275 multiple same attributes in the packet.
281 This attribute is reserved and it is never sent.
284 1 ATTRIBUTE_USER_INFO
286 This attribute includes general information about the user, their
287 name and contact information. The content of this attribute is
288 a VCard version 3.0 as defined in RFC 2426 [RFC2426] and RFC 2425
289 [RFC2425]. Note that some of the information that VCard provides
290 can be also provided in the means of providing other attributes.
291 The rationale for this is that the VCard does not provide all the
292 information, or with the required precision that may be desired in
293 some applications. It is therefore RECOMMENDED that this attribute
294 would be used to provide only basic and constant user information,
295 such as name and contact information, but not online status
299 variable VCard Basic user information
304 This attribute indicates a service in the Internet that the user
305 is currently using or has logged in. The value of this attribute
309 4 bytes integer Service Port (IANA specified)
310 variable string Service Address
311 1 byte boolean Online status. If this is set to
312 0x01 (true) it means the user is online
313 in the service. Set to 0x00 (false) when
317 3 ATTRIBUTE_STATUS_MOOD
319 This attribute indicates the mood of the user. It can indicate
320 whether the user is eager to participate in the network. The
321 value of this attribute is as follows:
324 4 bytes integer Mood mask (values ORed together)
326 The following mood values are defined:
328 0x00000000 MOOD_NORMAL
330 No specific mood, the normal mood for a user.
333 0x00000001 MOOD_HAPPY
335 The user feels happy.
343 0x00000004 MOOD_ANGRY
345 The user feels angry.
348 0x00000008 MOOD_JEALOUS
350 The user feels jealous.
353 0x00000010 MOOD_ASHAMED
355 The user feels ashamed.
358 0x00000020 MOOD_INVINCIBLE
360 The user feels invincible.
363 0x00000040 MOOD_INLOVE
365 The user feels being in love.
368 0x00000080 MOOD_SLEEPY
370 The user feels sleepy.
373 0x00000100 MOOD_BORED
375 The user feels bored.
378 0x00000200 MOOD_EXCITED
380 The user feels exited.
383 0x00000400 MOOD_ANXIOUS
385 The user feels anxious.
388 4 ATTRIBUTE_STATUS_FREETEXT
390 This attribute includes the user's online status free text. It
391 can provide personal status as a text message. The contents of
392 this attribute is a UTF-8 encoded free text string.
395 variable string Free text status string
398 5 ATTRIBUTE_STATUS_MESSAGE
400 This attribute includes the user's online status message. It
401 could provide for example a multi media message showing the status
402 of the user. The contents of this attribute is a MIME object,
403 which can be used to provide for example video, audio, image or
404 other similar status message. It could also provide a reference
405 to the message, for example an URL address.
408 variable MIME Status message as MIME object
411 6 ATTRIBUTE_STATUS_COMMUNICATION
416 7 ATTRIBUTE_PREFERRED_LANGUAGE
419 8 ATTRIBUTE_PREFERRED_CONTACT
424 This attribute can be used to provide the current local time for
425 the user. The contents of this attribute is a UTF-8 encoded
426 string and the format of the string is UTC time zone defined
430 variable string UTC date, format as in ISO 8601
432 Note that ATTRIBUTE_USER_INFO may also provide this information.
433 However it is RECOMMENDED that this attribute is used when
434 current time zone information is provided.
437 10 ATTRIBUTE_GEOLOCATION
439 This attribute can be used to provide measured global location of
440 the user. How this information is gathered is out of scope of
441 this document. The attribute can provide latitude and longitude
442 lateral positions, but also a vertical position. A parameter
443 describing the accuracy of the information can also be provided.
446 variable string Longitude
447 variable string Latitude
448 variable string Altitude
449 variable string Accuracy in meters
451 Note that ATTRIBUTE_USER_INFO may also provide this information,
452 however it does not have the vertical position, or the accuracy
453 parameter. It is RECOMMENDED that this attribute is used when
454 providing current global position information.
457 11 ATTRIBUTE_DEVICE_INFO
459 This attribute includes information about the user's device
460 The encoding of this attribute is as follows:
463 4 bytes integer Device type
464 variable string Name of the device manufacturer
465 variable string Device version
466 variable string Device model
467 variable string Device language (ISO 639-2/T)
469 The following Device types are defined:
471 0 DEVICE_COMPUTER Device is a computer
472 1 DEVICE_MOBILE_PHONE Device is a mobile phone
473 2 DEVICE_PDA Device is a PDA
474 3 DEVICE_TERMINAL Device is a terminal
477 12 ATTRIBUTE_EXTENSION
479 This attribute indicates that the attribute value is vendor,
480 application or service specific attribute extension. This field
481 MUST include a MIME object, which is the extension value. This
482 document does not specify any explicit MIME objects for this
486 variable MIME Attribute extension as MIME object
489 13 ATTRIBUTE_USER_PUBLIC_KEY
491 This attribute includes the user's public key or certificate.
492 As the public key and certificate format depends on which sort
493 of algorithm or certificate encoding user is using we need to
494 define a mechanism to differentiate the public key types from
495 each other. This document specifies the most common public keys
496 and certificates. This attribute can be used to deliver the
497 user's public key, and it MUST be present if also the
498 ATTRIBUTE_USER_DIGITAL_SIGNATURE is present. Note that the
499 recipient of this attribute SHOULD verify the public key from
500 a third party, for example from Certification Authority.
503 variable string Public key/certificate type
504 variable data Public key/certificate data
506 The following public key/certificate types are defined:
508 ssh-rsa SSH RSA public key [SSH-TRANS]
509 ssh-dss SSH DSS public key [SSH-TRANS]
510 silc-rsa SILC RSA public key [SILC1]
511 silc-dss SILC DSS public key [SILC1]
512 pgp-sign-rsa OpenPGP RSA certificate [RFC2440]
513 pgp-sign-dss OpenPGP DSS certificate [RFC2440]
514 x509v3-sign-rsa X.509 Version 3 RSA certificate [RFC2459]
515 x509v3-sign-dss X.509 Version 3 DSS certificate [RFC2459]
517 Most of these public key/certificate types are equivalent to
518 the types specified for SSH protocol [SSH-TRANS] and are expected
519 to be officially assigned by IANA.
521 The encoding of the public key/certificate data in the attribute
522 is done in the manner defined in their respective definitions.
524 Note that these public keys are intended for signing. Some
525 certificates may have a key usage restrictions and same key cannot
526 be used for both encryption and signing. Therefore, the name
527 of the certificate type indicates if they are intended for
531 14 ATTRIBUTE_SERVER_PUBLIC_KEY
533 This attribute includes a third party server or authority public
534 key or CA certificate and MUST be present if the attribute
535 ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also present. The format
536 for this attribute is identical to the ATTRIBUTE_USER_PUBLIC_KEY
540 15 ATTRIBUTE_USER_DIGITAL_SIGNATURE
542 This attribute value includes digital signature of all Attribute
543 Payloads except this attribute. This signature can be provided by
544 the user. This attribute SHOULD be last attribute provided in the
545 reply so that it is easier for the receiver to compute the signature
546 data to be verified. The format and encoding of this attribute
547 depends on the public key or certificate used to produce the
548 signature. See the ATTRIBUTE_USER_PUBLIC_KEY for all public keys
549 and certificates that can be used to produce a signature.
552 variable data Digital signature data
554 The encodings are as follows per public key/certificate type:
556 ssh-rsa and ssh-dss Defined in [SSH-TRANS]
557 silc-rsa and silc-dss Defined in [SILC1]
558 pgp-sign-rsa and pgp-sign-dss Defined in [RFC2440]
559 x509v3-sign-rsa and x509v3-sign-dss Defined in [PKCS7]
561 The procedure producing the signature and encoding it are done
562 in the manner defined in their respective definitions, see the
566 16 ATTRIBUTE_SERVER_DIGITAL_SIGNATURE
568 This attribute value includes digital signature of all Attribute
569 Payloads except this attribute, but including the attribute
570 ATTRIBUTE_USER_DIGITAL_SIGNATURE. This signature can be provided
571 by a third party server or an authority which has verified the
572 information provided by the user. How it verifies this information
573 is out of scope of this document, however it may base its
574 information to a previous registeration information and current
575 online status of the user in a service. This attribute SHOULD be
576 last when provided, so that it is easier for the receiver to
577 compute the signature data to be verified. The format for this
578 attribute is identical to the ATTRIBUTE_USER_DIGITAL_SIGNATURE
584 3 Security Considerations
591 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
592 Requirement Levels", BCP 14, RFC 2119, March 1997.
594 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
595 10646", RFC 2279, January 1998.
597 [RFC2425] Howes, T., et al, "A MIME Content-Type for Directory
598 Information", RFC 2425, September 1998.
600 [RFC2426] Dawson, F., et al, "vCard MIME Directory Profile",
601 RFC 2426, September 1998.
603 [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
604 Protocol Specification", Internet Draft, May 2002.
606 [RFC2440] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
609 [RFC2459] Housley, R., et al, "Internet X.509 Public Key
610 Infrastructure, Certificate and CRL Profile", RFC 2459,
613 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
616 [PKCS7] Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
617 Version 1.5", RFC 2315, March 1998.
624 Snellmaninkatu 34 A 15
628 EMail: priikone@iki.fi
630 This Internet-Draft expires 15 November 2002