1 .pl 10.0i
2 .po 0
3 .ll 7.2i
4 .lt 7.2i
5 .nr LL 7.2i
6 .nr LT 7.2i
7 .ds LF Riikonen
8 .ds RF FORMFEED[Page %]
9 .ds CF
10 .ds LH Internet Draft
11 .ds RH 2 February 2004
12 .ds CH
13 .na
14 .hy 0
15 .in 0
16 .nf
17 Network Working Group P. Riikonen
18 Internet-Draft
19 draft-riikonen-presence-attrs-03.txt 2 February 2004
20 Expires: 2 August 2004
21
22 .in 3
23
24 .ce 2
25 User Online Presence and Information Attributes
26 <draft-riikonen-presence-attrs-03.txt>
27
28 .ti 0
29 Status of this Memo
30
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.
36
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."
41
42 The list of current Internet-Drafts can be accessed at
43 http://www.ietf.org/ietf/1id-abstracts.txt
44
45 The list of Internet-Draft Shadow Directories can be accessed at
46 http://www.ietf.org/shadow.html
47
48 The distribution of this memo is unlimited.
49
50
51 .ti 0
52 Abstract
53
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
62 users in a network.
63
64
65
66
67
68
69
70 .ti 0
71 Table of Contents
72
73 .nf
74 1 Introduction .................................................. 2
75 1.1 Requirements Terminology .................................. 2
76 2 Attributes Concept ............................................ 3
77 2.1 Requesting Attributes ..................................... 3
78 2.2 Replying Attributes ....................................... 3
79 2.3 Attribute Data Types ...................................... 4
80 2.4 Attribute Payload ......................................... 4
81 2.5 Attributes ................................................ 5
82 3 Security Considerations ....................................... 11
83 4 References .................................................... 12
84 5 Author's Address .............................................. 13
85 6 Full Copyright Statement ...................................... 13
86
87
88 .ti 0
89 1. Introduction
90
91 This document defines set of attributes that can represent the online
92 user's presence in a network, and to provide general information about
93 the user. The purpose is to provide a generic mechanism to share
94 online presence and status, and general information about the user
95 to be used in several kind of network protocols and applications.
96 These attributes could be used by for example chat and conferencing
97 protocols (such as Instant Message protocols), network games, and
98 other similar network protocols and applications that has online
99 users in a network.
100
101 This document does not define these attributes to be used in any
102 specific protocol, but assumes that they can be used generally in
103 any kind of online network protocol. Furthermore, the document
104 pays attention to special needs of various protocols, such as
105 mobile network protocols, which requires the attributes to be
106 both robust and compact. The attributes are also considered to be
107 easily implementable and for this reason a clear and robust structure
108 was chosen for the attributes.
109
110 This document is strongly influenced by Wireless Village Initiative
111 where similar attributes are defined, and credits for the ideas are
112 due there. However, they are defined only in the context of the
113 Wireless Village, and the format of the attributes used is not
114 suitable for general purpose usage.
115
116
117 .ti 0
118 1.1 Requirements Terminology
119
120 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
121 MAY, and OPTIONAL, when they appear in this document, are to be
122 interpreted as described in [RFC2119].
123
124
125 .ti 0
126 2 Attributes Concept
127
128 Many network protocols needs a way to transfer and retrieve status
129 information about users in a network. For example, many chat and
130 conferencing protocols such as IRC, and all Instant Message (IM)
131 protocols, such as ICQ has a way to retrieve presence and status
132 information about the users in the network. This could be added to
133 several other kind of network protocols as well, and for this reason
134 a defined mechanism to provide these informations is needed.
135
136 The attributes are usually requested by an entity in the network
137 from other entity, usually a user or end user's device in the network.
138 The recipient then replies to each of the requested attributes and
139 sends the reply to the requester.
140
141 This document does not define the actual transport for requesting and
142 providing the replies to the requests, since this is irrelevant.
143 This document defines a payload for requesting, and providing the
144 information, but how the payload is transported is not defined in
145 this document. In a client-server network model the user requesting
146 attributes usually destine the request to a remote user and the
147 server relays the attributes to the remote user. It is also possible
148 that the concept is not user-to-user, but the server replies to the
149 requested attributes on behalf of the user.
150
151
152 .ti 0
153 2.1 Requesting Attributes
154
155 When an entity requests attributes from a user in the network,
156 it assembles a list of Attribute Payloads, and sets the requested
157 attribute value into the payload. Each requested attribute is a separate
158 Attribute Payload and they MUST be appended one after the other. The
159 requester need to understand that the recipient may not understand all
160 the requested attributes, and may not reply to all of the requested
161 attributes. The requester also need to understand that the recipient
162 may reply with additional attributes that were not requested.
163
164
165 .ti 0
166 2.2 Replying Attributes
167
168 When en entity receives the Attribute Payloads it parses them one after
169 the other. The entity can parse each of the Attribute Payload separately
170 since it knows the length of the current attribute; next attribute
171 begins after the current attribute ends. The entity then checks the
172 requested attribute and SHOULD reply either with valid value or with
173 an indication that the attribute is unsupported or unknown. It is
174 also possible to reply with additional attributes that were not
175 requested.
176
177 When replying to the requested attributes the entity assembles a list
178 of Attribute Payloads, each including the attribute type and the
179 actual attribute data.
180
181
182 .ti 0
183 2.3 Attribute Data Types
184
185 This section defines basic data types that can appear in the attributes
186 in this document.
187
188 All integer values are stored in the MSB first order. The size of the
189 integer is provided separately with the attribute. Integer is
190 represented as "integer" in this documentation.
191
192 Strings MUST be UTF-8 [RFC2279] encoded, and include 2 bytes length
193 field indicating the length of the string. Hence, when "string" value
194 appears in this documentation it is encoded as:
195
196 .in 6
197 Length Type Value
198 2 bytes integer Length of String field
199 variable UTF-8 String
200 .in 3
201
202 If string is not present then the length field includes zero (0)
203 value.
204
205 Boolean value is represented as "boolean" and its size is 1 byte.
206 Value 0x00 indicates false value and value 0x01 indicates true value.
207
208
209 .ti 0
210 2.4 Attribute Payload
211
212 The Attribute Payload is used to request an attribute, and to reply
213 to the requested attribute. One payload includes one attribute.
214
215
216 .in 5
217 .nf
218 1 2 3
219 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
220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
221 | Attribute | Attr Flags | Attribute Length |
222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
223 | |
224 ~ Attribute Data ~
225 | |
226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
227 .in 3
228
229 .ce
230 Figure 1: Attribute Payload
231
232
233 .in 6
234 o Attribute (1 byte) - Indicates the attribute included in this
235 Attribute Payload.
236
237 o Attribute Flags (1 byte) - Indicates the flags associated
238 with this attribute. The following flags are defined:
239
240 0x01 ATTRIBUTE_FLAG_INVALID
241
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.
246
247 0x02 ATTRIBUTE_FLAG_VALID
248
249 The attribute value is included in the Attribute Data.
250
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.
254
255 o Attribute Length (2 bytes) - Indicates the length of the
256 Attribute Data field, not including any other field.
257
258 o Attribute Data (variable length) - The Attribute Data.
259 The contents of this field is attribute specific, defined
260 subsequently.
261 .in 3
262
263
264 .ti 0
265 2.5 Attributes
266
267 The following values can appear in the Attribute field in the
268 Attribute Payload to indicate the content of the attribute. The
269 format of the attribute data is represented as length, type and
270 value. Example:
271
272 .in 6
273 Length Type Value
274 2 bytes integer Some integer value
275 variable string Some string
276 1 byte boolean Boolean value
277 .in 3
278
279 When sending multiple Attribute Payloads it is possible to include
280 multiple same attributes in the packet.
281
282
283 .in 6
284 0 ATTRIBUTE_NONE
285
286 This attribute is reserved and it is never sent.
287
288
289 1 ATTRIBUTE_USER_INFO
290
291 This attribute includes general information about the user, their
292 name and contact information. The content of this attribute is
293 a VCard version 3.0 as defined in RFC 2426 [RFC2426] and RFC 2425
294 [RFC2425]. Note that some of the information that VCard provides
295 can be also provided in the means of providing other attributes.
296 The rationale for this is that the VCard does not provide all the
297 information, or with the required precision that may be desired in
298 some applications. It is therefore RECOMMENDED that this attribute
299 would be used to provide only basic and constant user information,
300 such as name and contact information, but not online status
301 information.
302
303 Length Type Value
304 variable VCard Basic user information
305
306
307 2 ATTRIBUTE_SERVICE
308
309 This attribute indicates a service in the Internet that the user
310 is currently using or has logged in. It also shows when the user
311 started using the service, and how long user has been idle in the
312 service. The value of this attribute is as follows:
313
314 Length Type Value
315 4 bytes integer Service Port (IANA specified)
316 variable string Service Address
317 1 byte boolean Online status. If this is set to
318 0x01 (true) it means the user is online
319 in the service. Set to 0x00 (false) when
320 out of reach.
321 variable string Signon date and time, UTC date, format as
322 in ISO 8601
323 4 bytes integer Idle time
324
325
326 3 ATTRIBUTE_STATUS_MOOD
327
328 This attribute indicates the mood of the user. It can indicate
329 whether the user is eager to participate in the network. The
330 value of this attribute is as follows:
331
332 Length Type Value
333 4 bytes integer Mood mask (values ORed together)
334
335 The following mood values are defined:
336
337 0x00000000 MOOD_NORMAL No specific mood, normal mood
338 0x00000001 MOOD_HAPPY The user feels happy
339 0x00000002 MOOD_SAD The user feels sad
340 0x00000004 MOOD_ANGRY The user feels angry
341 0x00000008 MOOD_JEALOUS The user feels jealous
342 0x00000010 MOOD_ASHAMED The user feels ashamed
343 0x00000020 MOOD_INVINCIBLE The user feels invincible
344 0x00000040 MOOD_INLOVE The user feels being in love
345 0x00000080 MOOD_SLEEPY The user feels sleepy
346 0x00000100 MOOD_BORED The user feels bored
347 0x00000200 MOOD_EXCITED The user feels excited
348 0x00000400 MOOD_ANXIOUS The user feels anxious
349
350
351 4 ATTRIBUTE_STATUS_FREETEXT
352
353 This attribute includes the user's online status free text. It
354 can provide personal status as a text message. The contents of
355 this attribute is a UTF-8 encoded free text string.
356
357 Length Type Value
358 variable string Free text status string
359
360
361 5 ATTRIBUTE_STATUS_MESSAGE
362
363 This attribute includes the user's online status message. It
364 could provide for example a multi media message showing the status
365 of the user. The contents of this attribute is a MIME object,
366 which can be used to provide for example video, audio, image or
367 other similar status message. It could also provide a reference
368 to the message, for example an URL address.
369
370 Length Type Value
371 variable MIME Status message as MIME object
372
373
374 6 ATTRIBUTE_PREFERRED_LANGUAGE
375
376 This attribute indicates the preferred language to be used when
377 communicating. The encoding of this attribute is as follows:
378
379 Length Type Value
380 variable string ISO 639-2/T three letter code
381
382
383 7 ATTRIBUTE_PREFERRED_CONTACT
384
385 This attribute indicates the preferred contact methods. It can
386 indicate the method the user prefers when contacting. The value
387 of this attribute is as follows:
388
389 Length Type Value
390 4 bytes integer Contact mask (values ORed together)
391
392 The following contact methods are defined:
393
394 0x00000000 CONTACT_NONE No specific preferred contact method
395 0x00000001 CONTACT_EMAIL Email is preferred
396 0x00000002 CONTACT_CALL Phone call is preferred
397 0x00000004 CONTACT_PAGE Paging is preferred
398 0x00000008 CONTACT_SMS SMS is preferred
399 0x00000010 CONTACT_MMS MMS is preferred
400 0x00000020 CONTACT_CHAT Chatting is preferred
401 0x00000040 CONTACT_VIDEO Video conferencing is preferred
402
403
404 8 ATTRIBUTE_TIMEZONE
405
406 This attribute can be used to provide the current local time for
407 the user. The contents of this attribute is a UTF-8 encoded
408 string and the format of the string is UTC time zone defined
409 in the ISO 8601.
410
411 Length Type Value
412 variable string UTC date, format as in ISO 8601
413
414 Note that ATTRIBUTE_USER_INFO may also provide this information.
415 However it is RECOMMENDED that this attribute is used when
416 current time zone information is provided.
417
418
419 9 ATTRIBUTE_GEOLOCATION
420
421 This attribute can be used to provide measured global location of
422 the user. How this information is gathered is out of scope of
423 this document. The attribute can provide latitude and longitude
424 lateral positions, but also a vertical position. A parameter
425 describing the accuracy of the information can also be provided.
426
427 Length Type Value
428 variable string Longitude (ex. 31 17 14.321W)
429 variable string Latitude (ex. 12 11 21.2N)
430 variable string Altitude
431 variable string Accuracy in meters
432
433 Note that ATTRIBUTE_USER_INFO may also provide this information,
434 however it does not have the vertical position, or the accuracy
435 parameter. It is RECOMMENDED that this attribute is used when
436 providing current global position information.
437
438
439 10 ATTRIBUTE_DEVICE_INFO
440
441 This attribute includes information about the user's device.
442 The encoding of this attribute is as follows:
443
444 Length Type Value
445 4 bytes integer Device type
446 variable string Name of the device manufacturer
447 variable string Device version
448 variable string Device model
449 variable string Device language (ISO 639-2/T)
450
451 The following Device types are defined:
452
453 0 DEVICE_COMPUTER Device is a computer
454 1 DEVICE_MOBILE_PHONE Device is a mobile phone
455 2 DEVICE_PDA Device is a PDA
456 3 DEVICE_TERMINAL Device is a terminal
457
458
459 11 ATTRIBUTE_EXTENSION
460
461 This attribute indicates that the attribute value is vendor,
462 application or service specific attribute extension. This field
463 MUST include a MIME object, which is the extension value. This
464 document does not specify any explicit MIME objects for this
465 attribute.
466
467 Length Type Value
468 variable MIME Attribute extension as MIME object
469
470
471 12 ATTRIBUTE_USER_PUBLIC_KEY
472
473 This attribute includes the user's public key or certificate.
474 As the public key and certificate format depends on which sort
475 of algorithm or certificate encoding user is using we need to
476 define a mechanism to differentiate the public key types from
477 each other. This document specifies the most common public keys
478 and certificates. This attribute can be used to deliver the
479 user's public key, and it MUST be present if also the
480 ATTRIBUTE_USER_DIGITAL_SIGNATURE is present. Note that the
481 recipient of this attribute SHOULD verify the public key from
482 a third party, for example from Certification Authority. If
483 there are more than one ATTRIBUTE_USER_PUBLIC_KEY attributes set
484 and ATTRIBUTE_USER_DIGITAL_SIGNATURE is also set, the digital
485 signature SHOULD be verifiable with the first set public key.
486
487 Length Type Value
488 variable string Public key/certificate type
489 variable data Public key/certificate data
490
491 The following public key/certificate types are defined:
492
493 ssh-rsa SSH RSA public key [SSH-TRANS]
494 ssh-dss SSH DSS public key [SSH-TRANS]
495 silc-rsa SILC RSA public key [SILC1]
496 silc-dss SILC DSS public key [SILC1]
497 pgp-sign-rsa OpenPGP RSA certificate [RFC2440]
498 pgp-sign-dss OpenPGP DSS certificate [RFC2440]
499 x509v3-sign-rsa X.509 Version 3 RSA certificate [RFC2459]
500 x509v3-sign-dss X.509 Version 3 DSS certificate [RFC2459]
501
502 Most of these public key/certificate types are equivalent to
503 the types specified for SSH protocol [SSH-TRANS] and are expected
504 to be officially assigned by IANA.
505
506 The encoding of the public key/certificate data in the attribute
507 is done in the manner defined in their respective definitions.
508
509 Note that these public keys are intended for signing. Some
510 certificates may have a key usage restrictions and same key cannot
511 be used for both encryption and signing. Therefore, the name
512 of the certificate type indicates if they are intended for
513 signing only.
514
515
516 13 ATTRIBUTE_SERVER_PUBLIC_KEY
517
518 This attribute includes a third party server or authority public
519 key or CA certificate and MUST be present if the attribute
520 ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also present. The format
521 for this attribute is identical to the ATTRIBUTE_USER_PUBLIC_KEY
522 attribute. If there are more than one ATTRIBUTE_SERVER_PUBLIC_KEY
523 attributes set and ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also set,
524 the digital signature SHOULD be verifiable with the first set public
525 key.
526
527
528 14 ATTRIBUTE_USER_DIGITAL_SIGNATURE
529
530 This attribute value includes digital signature of all Attribute
531 Payloads except this attribute. This signature can be provided by
532 the user. This attribute SHOULD be last attribute provided in the
533 reply so that it is easier for the receiver to compute the signature
534 data to be verified. The format and encoding of this attribute
535 depends on the public key or certificate used to produce the
536 signature. See the ATTRIBUTE_USER_PUBLIC_KEY for all public keys
537 and certificates that can be used to produce a signature.
538
539 Length Type Value
540 variable data Digital signature data
541
542 The encodings are as follows per public key/certificate type:
543
544 ssh-rsa and ssh-dss Defined in [SSH-TRANS]
545 silc-rsa and silc-dss Defined in [SILC1]
546 pgp-sign-rsa and pgp-sign-dss Defined in [RFC2440]
547 x509v3-sign-rsa and x509v3-sign-dss Defined in [PKCS7]
548
549 The procedure producing the signature and encoding it are done
550 in the manner defined in their respective definitions, see the
551 provided references. Also the hash function used with the
552 signature procedure is defined by the public key/certificate type.
553
554
555 15 ATTRIBUTE_SERVER_DIGITAL_SIGNATURE
556
557 This attribute value includes digital signature of all Attribute
558 Payloads except this attribute, but including the attribute
559 ATTRIBUTE_USER_DIGITAL_SIGNATURE. This signature can be provided
560 by a third party server or an authority which has verified the
561 information provided by the user. How it verifies this information
562 is out of scope of this document, however it may base its
563 information to a previous registration information and current
564 online status of the user in a service. This attribute SHOULD be
565 last when provided, so that it is easier for the receiver to
566 compute the signature data to be verified. The format for this
567 attribute is identical to the ATTRIBUTE_USER_DIGITAL_SIGNATURE
568 attribute.
569 .in 3
570
571
572 .ti 0
573 3 Security Considerations
574
575 The use of these attributes dictates whether the attributes need to
576 be secured or not. However, as the attributes are considered to provide
577 accurate status information about specific user, it is suggested that
578 the attributes would be secured. The attributes should be digitally
579 signed whenever it is possible. Attributes can also be encrypted
580 if it is provided by the protocol using the attributes. A third party,
581 like a server in the network, could also verify the information and provide
582 digital signature in case the information is accurate.
583
584 Even though the attributes would be digitally signed by the sender of
585 the attributes, the information contained in the attribute may still
586 be incorrect. The third party server should not apply digital signature
587 unless it can verify every attribute. The receiver of the attributes
588 should also not trust that the information in fact is correct.
589
590 However, it is possible that the context where these attributes are used
591 the attributes are provided by a party that can provide the accurate
592 information. For example a server in the network could reply to the
593 attributes on behalf of the actual user for some of the attributes.
594
595
596 .ti 0
597 4 References
598
599 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
600 Requirement Levels", BCP 14, RFC 2119, March 1997.
601
602 [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
603 10646", RFC 2279, January 1998.
604
605 [RFC2425] Howes, T., et al, "A MIME Content-Type for Directory
606 Information", RFC 2425, September 1998.
607
608 [RFC2426] Dawson, F., et al, "vCard MIME Directory Profile",
609 RFC 2426, September 1998.
610
611 [SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC),
612 Protocol Specification", Internet Draft, May 2002.
613
614 [RFC2440] Callas, J., et al, "OpenPGP Message Format", RFC 2440,
615 November 1998.
616
617 [RFC2459] Housley, R., et al, "Internet X.509 Public Key
618 Infrastructure, Certificate and CRL Profile", RFC 2459,
619 January 1999.
620
621 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol",
622 Internet Draft.
623
624 [PKCS7] Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
625 Version 1.5", RFC 2315, March 1998.
626
627
628
629
630 .ti 0
631 5 Author's Address
632
633 Pekka Riikonen
634 Snellmaninkatu 34 A 15
635 70100 Kuopio
636 Finland
637
638 EMail: priikone@iki.fi
639
640
641 .ti 0
642 6 Full Copyright Statement
643
644 Copyright (C) The Internet Society (2003). All Rights Reserved.
645
646 This document and translations of it may be copied and furnished to
647 others, and derivative works that comment on or otherwise explain it
648 or assist in its implementation may be prepared, copied, published
649 and distributed, in whole or in part, without restriction of any
650 kind, provided that the above copyright notice and this paragraph are
651 included on all such copies and derivative works. However, this
652 document itself may not be modified in any way, such as by removing
653 the copyright notice or references to the Internet Society or other
654 Internet organizations, except as needed for the purpose of
655 developing Internet standards in which case the procedures for
656 copyrights defined in the Internet Standards process must be
657 followed, or as required to translate it into languages other than
658 English.
659
660 The limited permissions granted above are perpetual and will not be
661 revoked by the Internet Society or its successors or assigns.
662
663 This document and the information contained herein is provided on an
664 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
665 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
666 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
667 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
668 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
669
This page was automatically generated by the LXR engine.
Free-text search provided by Glimpse