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