7 Network Working Group P. Riikonen
9 draft-riikonen-presence-attrs-04.txt 15 January 2007
13 User Online Presence and Information Attributes
14 <draft-riikonen-presence-attrs-04.txt>
18 By submitting this Internet-Draft, each author represents that any
19 applicable patent or other IPR claims of which he or she is aware
20 have been or will be disclosed, and any of which he or she becomes
21 aware will be disclosed, in accordance with Section 6 of BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as Internet-
26 Drafts. Internet-Drafts are draft documents valid for a maximum of
27 six months and may be updated, replaced, or obsoleted by other
28 documents at any time. It is inappropriate to use Internet-Drafts as
29 reference material or to cite them other than as "work in progress".
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/1id-abstracts.html
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
40 This document defines set of attributes that can represent the online
41 user's presence in a network, and to provide general information about
42 the user. The purpose is to provide a generic mechanism to share
43 online presence and status, and general information about the user
44 to be used in several kind of network protocols and applications.
45 These attributes could be used by for example chat and conferencing
46 protocols (such as Instant Message protocols), network games, and
47 other similar network protocols and applications that has online
60 Internet Draft 15 January 2007
65 1 Introduction .................................................. 2
66 1.1 Requirements Terminology .................................. 2
67 2 Attributes Concept ............................................ 3
68 2.1 Requesting Attributes ..................................... 3
69 2.2 Replying Attributes ....................................... 3
70 2.3 Attribute Data Types ...................................... 4
71 2.4 Attribute Payload ......................................... 4
72 2.5 Attributes ................................................ 5
73 3 Security Considerations ....................................... 12
74 4 References .................................................... 12
75 5 Author's Address .............................................. 13
76 6 Full Copyright Statement ...................................... 13
81 This document defines set of attributes that can represent the online
82 user's presence in a network, and to provide general information about
83 the user. The purpose is to provide a generic mechanism to share
84 online presence and status, and general information about the user
85 to be used in several kind of network protocols and applications.
86 These attributes could be used by for example chat and conferencing
87 protocols (such as Instant Message protocols), network games, and
88 other similar network protocols and applications that has online
91 This document does not define these attributes to be used in any
92 specific protocol, but assumes that they can be used generally in
93 any kind of online network protocol. Furthermore, the document
94 pays attention to special needs of various protocols, such as
95 mobile network protocols, which requires the attributes to be
96 both robust and compact. The attributes are also considered to be
97 easily implementable and for this reason a clear and robust structure
98 was chosen for the attributes.
100 This document is strongly influenced by Wireless Village Initiative
101 where similar attributes are defined, and credits for the ideas are
102 due there. However, they are defined only in the context of the
103 Wireless Village, and the format of the attributes used is not
104 suitable for general purpose usage.
107 1.1 Requirements Terminology
109 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
110 MAY, and OPTIONAL, when they appear in this document, are to be
116 Internet Draft 15 January 2007
119 interpreted as described in [RFC2119].
124 Many network protocols needs a way to transfer and retrieve status
125 information about users in a network. For example, many chat and
126 conferencing protocols such as IRC, and all Instant Message (IM)
127 protocols, such as ICQ has a way to retrieve presence and status
128 information about the users in the network. This could be added to
129 several other kind of network protocols as well, and for this reason
130 a defined mechanism to provide these informations is needed.
132 The attributes are usually requested by an entity in the network
133 from other entity, usually a user or end user's device in the network.
134 The recipient then replies to each of the requested attributes and
135 sends the reply to the requester.
137 This document does not define the actual transport for requesting and
138 providing the replies to the requests, since this is irrelevant.
139 This document defines a payload for requesting, and providing the
140 information, but how the payload is transported is not defined in
141 this document. In a client-server network model the user requesting
142 attributes usually destine the request to a remote user and the
143 server relays the attributes to the remote user. It is also possible
144 that the concept is not user-to-user, but the server replies to the
145 requested attributes on behalf of the user.
148 2.1 Requesting Attributes
150 When an entity requests attributes from a user in the network,
151 it assembles a list of Attribute Payloads, and sets the requested
152 attribute value into the payload. Each requested attribute is a separate
153 Attribute Payload and they MUST be appended one after the other. The
154 requester need to understand that the recipient may not understand all
155 the requested attributes, and may not reply to all of the requested
156 attributes. The requester also need to understand that the recipient
157 may reply with additional attributes that were not requested.
160 2.2 Replying Attributes
162 When en entity receives the Attribute Payloads it parses them one after
163 the other. The entity can parse each of the Attribute Payload separately
164 since it knows the length of the current attribute; next attribute
165 begins after the current attribute ends. The entity then checks the
166 requested attribute and SHOULD reply either with valid value or with
172 Internet Draft 15 January 2007
175 an indication that the attribute is unsupported or unknown. It is
176 also possible to reply with additional attributes that were not
179 When replying to the requested attributes the entity assembles a list
180 of Attribute Payloads, each including the attribute type and the
181 actual attribute data.
184 2.3 Attribute Data Types
186 This section defines basic data types that can appear in the attributes
189 All integer values are stored in the MSB first order. The size of the
190 integer is provided separately with the attribute. Integer is
191 represented as "integer" in this documentation.
193 Strings MUST be UTF-8 [RFC2279] encoded, and include 2 bytes length
194 field indicating the length of the string. Hence, when "string" value
195 appears in this documentation it is encoded as:
198 2 bytes integer Length of String field
199 variable UTF-8 String
201 If string is not present then the length field includes zero (0)
204 Boolean value is represented as "boolean" and its size is 1 byte.
205 Value 0x00 indicates false value and value 0x01 indicates true value.
208 2.4 Attribute Payload
210 The Attribute Payload is used to request an attribute, and to reply
211 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
228 Internet Draft 15 January 2007
231 Figure 1: Attribute Payload
234 o Attribute (1 byte) - Indicates the attribute included in this
237 o Attribute Flags (1 byte) - Indicates the flags associated
238 with this attribute. The following flags are defined:
240 0x01 ATTRIBUTE_FLAG_INVALID
242 The attribute value in Attribute Data is invalid, or
243 unknown. This may be set to indicate that a requested
244 attribute is not available, its value is unknown, or
245 sender does not understand it.
247 0x02 ATTRIBUTE_FLAG_VALID
249 The attribute value is included in the Attribute Data.
251 When sending this payload to request attributes this value
252 MUST be set to zero (0) value. When sending a reply to the
253 request this field MUST NOT include a zero (0) value.
255 o Attribute Length (2 bytes) - Indicates the length of the
256 Attribute Data field, not including any other field.
258 o Attribute Data (variable length) - The Attribute Data.
259 The contents of this field is attribute specific, defined
265 The following values can appear in the Attribute field in the
266 Attribute Payload to indicate the content of the attribute. The
267 format of the attribute data is represented as length, type and
271 2 bytes integer Some integer value
272 variable string Some string
273 1 byte boolean Boolean value
275 When sending multiple Attribute Payloads it is possible to include
276 multiple same attributes in the packet.
284 Internet Draft 15 January 2007
289 This attribute is reserved and it is never sent.
292 1 ATTRIBUTE_USER_INFO
294 This attribute includes general information about the user, their
295 name and contact information. The content of this attribute is
296 a VCard version 3.0 as defined in RFC 2426 [RFC2426] and RFC 2425
297 [RFC2425]. Note that some of the information that VCard provides
298 can be also provided in the means of providing other attributes.
299 The rationale for this is that the VCard does not provide all the
300 information, or with the required precision that may be desired in
301 some applications. It is therefore RECOMMENDED that this attribute
302 would be used to provide only basic and constant user information,
303 such as name and contact information, but not online status
307 variable VCard Basic user information
312 This attribute indicates a service in the Internet that the user
313 is currently using or has logged in. It also shows when the user
314 started using the service, and how long user has been idle in the
315 service. The value of this attribute is as follows:
318 4 bytes integer Service Port (IANA specified)
319 variable string Service Address
320 1 byte boolean Online status. If this is set to
321 0x01 (true) it means the user is online
322 in the service. Set to 0x00 (false) when
324 variable string Signon date and time, UTC date, format as
326 4 bytes integer Idle time
329 3 ATTRIBUTE_STATUS_MOOD
331 This attribute indicates the mood of the user. It can indicate
332 whether the user is eager to participate in the network. The
333 value of this attribute is as follows:
340 Internet Draft 15 January 2007
344 4 bytes integer Mood mask (values ORed together)
346 The following mood values are defined:
348 0x00000000 MOOD_NORMAL No specific mood, normal mood
349 0x00000001 MOOD_HAPPY The user feels happy
350 0x00000002 MOOD_SAD The user feels sad
351 0x00000004 MOOD_ANGRY The user feels angry
352 0x00000008 MOOD_JEALOUS The user feels jealous
353 0x00000010 MOOD_ASHAMED The user feels ashamed
354 0x00000020 MOOD_INVINCIBLE The user feels invincible
355 0x00000040 MOOD_INLOVE The user feels being in love
356 0x00000080 MOOD_SLEEPY The user feels sleepy
357 0x00000100 MOOD_BORED The user feels bored
358 0x00000200 MOOD_EXCITED The user feels excited
359 0x00000400 MOOD_ANXIOUS The user feels anxious
362 4 ATTRIBUTE_STATUS_FREETEXT
364 This attribute includes the user's online status free text. It
365 can provide personal status as a text message. The contents of
366 this attribute is a UTF-8 encoded free text string.
369 variable string Free text status string
372 5 ATTRIBUTE_STATUS_MESSAGE
374 This attribute includes the user's online status message. It
375 could provide for example a multi media message showing the status
376 of the user. The contents of this attribute is a MIME object,
377 which can be used to provide for example video, audio, image or
378 other similar status message. It could also provide a reference
379 to the message, for example an URL address.
382 variable MIME Status message as MIME object
385 6 ATTRIBUTE_PREFERRED_LANGUAGE
387 This attribute indicates the preferred language to be used when
388 communicating. The encoding of this attribute is as follows:
396 Internet Draft 15 January 2007
399 variable string ISO 639-2/T three letter code
402 7 ATTRIBUTE_PREFERRED_CONTACT
404 This attribute indicates the preferred contact methods. It can
405 indicate the method the user prefers when contacting. The value
406 of this attribute is as follows:
409 4 bytes integer Contact mask (values ORed together)
411 The following contact methods are defined:
413 0x00000000 CONTACT_NONE No specific preferred contact method
414 0x00000001 CONTACT_EMAIL Email is preferred
415 0x00000002 CONTACT_CALL Phone call is preferred
416 0x00000004 CONTACT_PAGE Paging is preferred
417 0x00000008 CONTACT_SMS SMS is preferred
418 0x00000010 CONTACT_MMS MMS is preferred
419 0x00000020 CONTACT_CHAT Chatting is preferred
420 0x00000040 CONTACT_VIDEO Video conferencing is preferred
425 This attribute can be used to provide the current local time for
426 the user. The contents of this attribute is a UTF-8 encoded
427 string and the format of the string is UTC time zone defined
431 variable string UTC date, format as in ISO 8601
433 Note that ATTRIBUTE_USER_INFO may also provide this information.
434 However it is RECOMMENDED that this attribute is used when
435 current time zone information is provided.
438 9 ATTRIBUTE_GEOLOCATION
440 This attribute can be used to provide measured global location of
441 the user. How this information is gathered is out of scope of
442 this document. The attribute can provide latitude and longitude
443 lateral positions, but also a vertical position. A parameter
444 describing the accuracy of the information can also be provided.
452 Internet Draft 15 January 2007
455 variable string Longitude (ex. 31 17 14.321W)
456 variable string Latitude (ex. 12 11 21.2N)
457 variable string Altitude
458 variable string Accuracy in meters
460 Note that ATTRIBUTE_USER_INFO may also provide this information,
461 however it does not have the vertical position, or the accuracy
462 parameter. It is RECOMMENDED that this attribute is used when
463 providing current global position information.
466 10 ATTRIBUTE_DEVICE_INFO
468 This attribute includes information about the user's device.
469 The encoding of this attribute is as follows:
472 4 bytes integer Device type
473 variable string Name of the device manufacturer
474 variable string Device version
475 variable string Device model
476 variable string Device language (ISO 639-2/T)
478 The following Device types are defined:
480 0 DEVICE_COMPUTER Device is a computer
481 1 DEVICE_MOBILE_PHONE Device is a mobile phone
482 2 DEVICE_PDA Device is a PDA
483 3 DEVICE_TERMINAL Device is a terminal
486 11 ATTRIBUTE_EXTENSION
488 This attribute indicates that the attribute value is vendor,
489 application or service specific attribute extension. This field
490 MUST include a MIME object, which is the extension value. This
491 document does not specify any explicit MIME objects for this
495 variable MIME Attribute extension as MIME object
498 12 ATTRIBUTE_USER_PUBLIC_KEY
500 This attribute includes the user's public key or certificate.
501 As the public key and certificate format depends on which sort
502 of algorithm or certificate encoding user is using we need to
508 Internet Draft 15 January 2007
511 define a mechanism to differentiate the public key types from
512 each other. This document specifies the most common public keys
513 and certificates. This attribute can be used to deliver the
514 user's public key, and it MUST be present if also the
515 ATTRIBUTE_USER_DIGITAL_SIGNATURE is present. Note that the
516 recipient of this attribute SHOULD verify the public key from
517 a third party, for example from Certification Authority. If
518 there are more than one ATTRIBUTE_USER_PUBLIC_KEY attributes set
519 and ATTRIBUTE_USER_DIGITAL_SIGNATURE is also set, the digital
520 signature SHOULD be verifiable with the first set public key.
523 variable string Public key/certificate type
524 variable data Public key/certificate data
526 The following public key/certificate types are defined:
528 ssh-rsa SSH RSA public key [SSH-TRANS]
529 ssh-dss SSH DSS public key [SSH-TRANS]
530 silc-rsa SILC RSA public key [SILC1]
531 silc-dss SILC DSS public key [SILC1]
532 pgp-sign-rsa OpenPGP RSA certificate [RFC2440]
533 pgp-sign-dss OpenPGP DSS certificate [RFC2440]
534 x509v3-sign-rsa X.509 Version 3 RSA certificate [RFC2459]
535 x509v3-sign-dss X.509 Version 3 DSS certificate [RFC2459]
537 Most of these public key/certificate types are equivalent to
538 the types specified for SSH protocol [SSH-TRANS] and are expected
539 to be officially assigned by IANA.
541 The encoding of the public key/certificate data in the attribute
542 is done in the manner defined in their respective definitions.
544 Note that these public keys are intended for signing. Some
545 certificates may have a key usage restrictions and same key cannot
546 be used for both encryption and signing. Therefore, the name
547 of the certificate type indicates if they are intended for
551 13 ATTRIBUTE_SERVER_PUBLIC_KEY
553 This attribute includes a third party server or authority public
554 key or CA certificate and MUST be present if the attribute
555 ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also present. The format
556 for this attribute is identical to the ATTRIBUTE_USER_PUBLIC_KEY
557 attribute. If there are more than one ATTRIBUTE_SERVER_PUBLIC_KEY
558 attributes set and ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also set,
564 Internet Draft 15 January 2007
567 the digital signature SHOULD be verifiable with the first set public
571 14 ATTRIBUTE_USER_DIGITAL_SIGNATURE
573 This attribute value includes digital signature of all Attribute
574 Payloads except this attribute. This signature can be provided by
575 the user. This attribute SHOULD be last attribute provided in the
576 reply so that it is easier for the receiver to compute the signature
577 data to be verified. The format and encoding of this attribute
578 depends on the public key or certificate used to produce the
579 signature. See the ATTRIBUTE_USER_PUBLIC_KEY for all public keys
580 and certificates that can be used to produce a signature.
583 variable data Digital signature data
585 The encodings are as follows per public key/certificate type:
587 ssh-rsa and ssh-dss Defined in [SSH-TRANS]
588 silc-rsa and silc-dss Defined in [SILC1]
589 pgp-sign-rsa and pgp-sign-dss Defined in [RFC2440]
590 x509v3-sign-rsa and x509v3-sign-dss Defined in [PKCS7]
592 The procedure producing the signature and encoding it are done
593 in the manner defined in their respective definitions, see the
594 provided references. Also the hash function used with the
595 signature procedure is defined by the public key/certificate type.
598 15 ATTRIBUTE_SERVER_DIGITAL_SIGNATURE
600 This attribute value includes digital signature of all Attribute
601 Payloads except this attribute, but including the attribute
602 ATTRIBUTE_USER_DIGITAL_SIGNATURE. This signature can be provided
603 by a third party server or an authority which has verified the
604 information provided by the user. How it verifies this information
605 is out of scope of this document, however it may base its
606 information to a previous registration information and current
607 online status of the user in a service. This attribute SHOULD be
608 last when provided, so that it is easier for the receiver to
609 compute the signature data to be verified. The format for this
610 attribute is identical to the ATTRIBUTE_USER_DIGITAL_SIGNATURE
614 16 ATTRIBUTE_USER_ICON
620 Internet Draft 15 January 2007
623 This attribute includes the user's icon or picture that can be
624 associated with the user in the application's user interface.
625 The attribute is a MIME object of which content MUST be one of
626 the MIME image media types.
629 variable MIME Icon as MIME image message
632 3 Security Considerations
634 The use of these attributes dictates whether the attributes need to
635 be secured or not. However, as the attributes are considered to provide
636 accurate status information about specific user, it is suggested that
637 the attributes would be secured. The attributes should be digitally
638 signed whenever it is possible. Attributes can also be encrypted
639 if it is provided by the protocol using the attributes. A third party,
640 like a server in the network, could also verify the information and provide
641 digital signature in case the information is accurate.
643 Even though the attributes would be digitally signed by the sender of
644 the attributes, the information contained in the attribute may still
645 be incorrect. The third party server should not apply digital signature
646 unless it can verify every attribute. The receiver of the attributes
647 should also not trust that the information in fact is correct.
649 However, it is possible that the context where these attributes are used
650 the attributes are provided by a party that can provide the accurate
651 information. For example a server in the network could reply to the
652 attributes on behalf of the actual user for some of the attributes.
657 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
658 Requirement Levels", BCP 14, RFC 2119, March 1997.
660 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
661 10646", RFC 2279, January 1998.
663 [RFC2425] Howes, T., et al, "A MIME Content-Type for Directory
664 Information", RFC 2425, September 1998.
666 [RFC2426] Dawson, F., et al, "vCard MIME Directory Profile",
667 RFC 2426, September 1998.
669 [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
670 Protocol Specification", Internet Draft, January 2007.
676 Internet Draft 15 January 2007
679 [RFC2440] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
682 [RFC2459] Housley, R., et al, "Internet X.509 Public Key
683 Infrastructure, Certificate and CRL Profile", RFC 2459,
686 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
689 [PKCS7] Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
690 Version 1.5", RFC 2315, March 1998.
701 EMail: priikone@iki.fi
704 6 Full Copyright Statement
706 Copyright (C) The Internet Society (2007).
708 This document is subject to the rights, licenses and restrictions
709 contained in BCP 78, and except as set forth therein, the authors
710 retain all their rights.
712 This document and the information contained herein are provided on an
713 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
714 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
715 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
716 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
717 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
718 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.