doc/draft-riikonen-presence-attrs-01.nroff

   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.  If
 477      there are more than one ATTRIBUTE_USER_PUBLIC_KEY attributes set
 478      and ATTRIBUTE_USER_DIGITAL_SIGNATURE is also set, the digital
 479      signature SHOULD be verifiable with the first set public key.
 480
 481      Length       Type       Value
 482      variable     string     Public key/certificate type
 483      variable     data       Public key/certificate data
 484
 485      The following public key/certificate types are defined:
 486
 487      ssh-rsa           SSH RSA public key [SSH-TRANS]
 488      ssh-dss           SSH DSS public key [SSH-TRANS]
 489      silc-rsa          SILC RSA public key [SILC1]
 490      silc-dss          SILC DSS public key [SILC1]
 491      pgp-sign-rsa      OpenPGP RSA certificate [RFC2440]
 492      pgp-sign-dss      OpenPGP DSS certificate [RFC2440]
 493      x509v3-sign-rsa   X.509 Version 3 RSA certificate [RFC2459]
 494      x509v3-sign-dss   X.509 Version 3 DSS certificate [RFC2459]
 495
 496      Most of these public key/certificate types are equivalent to
 497      the types specified for SSH protocol [SSH-TRANS] and are expected
 498      to be officially assigned by IANA.
 499
 500      The encoding of the public key/certificate data in the attribute
 501      is done in the manner defined in their respective definitions.
 502
 503      Note that these public keys are intended for signing.  Some
 504      certificates may have a key usage restrictions and same key cannot
 505      be used for both encryption and signing.  Therefore, the name
 506      of the certificate type indicates if they are intended for
 507      signing only.
 508
 509
 510 13   ATTRIBUTE_SERVER_PUBLIC_KEY
 511
 512      This attribute includes a third party server or authority public
 513      key or CA certificate and MUST be present if the attribute
 514      ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also present.  The format
 515      for this attribute is identical to the ATTRIBUTE_USER_PUBLIC_KEY
 516      attribute.  If there are more than one ATTRIBUTE_SERVER_PUBLIC_KEY
 517      attributes set and ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also set,
 518      the digital signature SHOULD be verifiable with the first set public
 519      key.
 520
 521
 522 14   ATTRIBUTE_USER_DIGITAL_SIGNATURE
 523
 524      This attribute value includes digital signature of all Attribute
 525      Payloads except this attribute.  This signature can be provided by
 526      the user.  This attribute SHOULD be last attribute provided in the
 527      reply so that it is easier for the receiver to compute the signature
 528      data to be verified.  The format and encoding of this attribute
 529      depends on the public key or certificate used to produce the
 530      signature.  See the ATTRIBUTE_USER_PUBLIC_KEY for all public keys
 531      and certificates that can be used to produce a signature.
 532
 533      Length       Type       Value
 534      variable     data       Digital signature data
 535
 536      The encodings are as follows per public key/certificate type:
 537
 538      ssh-rsa and ssh-dss                   Defined in [SSH-TRANS]
 539      silc-rsa and silc-dss                 Defined in [SILC1]
 540      pgp-sign-rsa and pgp-sign-dss         Defined in [RFC2440]
 541      x509v3-sign-rsa and x509v3-sign-dss   Defined in [PKCS7]
 542
 543      The procedure producing the signature and encoding it are done
 544      in the manner defined in their respective definitions, see the
 545      provided references.
 546
 547
 548 15   ATTRIBUTE_SERVER_DIGITAL_SIGNATURE
 549
 550      This attribute value includes digital signature of all Attribute
 551      Payloads except this attribute, but including the attribute
 552      ATTRIBUTE_USER_DIGITAL_SIGNATURE.  This signature can be provided
 553      by a third party server or an authority which has verified the
 554      information provided by the user.  How it verifies this information
 555      is out of scope of this document, however it may base its
 556      information to a previous registration information and current
 557      online status of the user in a service.  This attribute SHOULD be
 558      last when provided, so that it is easier for the receiver to
 559      compute the signature data to be verified.  The format for this
 560      attribute is identical to the ATTRIBUTE_USER_DIGITAL_SIGNATURE
 561      attribute.
 562 .in 3
 563
 564
 565 .ti 0
 566 3 Security Considerations
 567
 568 The use of these attributes dictates whether the attributes need to
 569 be secured or not.  However, as the attributes are considered to provide
 570 accurate status information about specific user, it is suggested that
 571 the attributes would be secured.  The attributes should be digitally
 572 signed whenever it is possible.  Attributes can also be encrypted
 573 if it is provided by the protocol using the attributes.  A third party,
 574 like a server in the network, could also verify the information and provide
 575 digital signature in case the information is accurate.
 576
 577 Even though the attributes would be digitally signed by the sender of
 578 the attributes, the information contained in the attribute may still
 579 be incorrect.  The third party server should not apply digital signature
 580 unless it can verify every attribute.  The receiver of the attributes
 581 should also not trust that the information infact is correct.
 582
 583 However, it is possible that the context where these attributes are used
 584 the attributes are provided by a party that can provide the accurate
 585 information.  For example a server in the network could reply to the
 586 attributes on behalf of the actual user for some of the attributes.
 587
 588
 589 .ti 0
 590 4 References
 591
 592 [RFC2119]    Bradner, S., "Key Words for use in RFCs to Indicate
 593              Requirement Levels", BCP 14, RFC 2119, March 1997.
 594
 595 [RFC2279]    Yergeau, F., "UTF-8, a transformation format of ISO
 596              10646", RFC 2279, January 1998.
 597
 598 [RFC2425]    Howes, T., et al, "A MIME Content-Type for Directory
 599              Information", RFC 2425, September 1998.
 600
 601 [RFC2426]    Dawson, F., et al, "vCard MIME Directory Profile",
 602              RFC 2426, September 1998.
 603
 604 [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
 605              Protocol Specification", Internet Draft, May 2002.
 606
 607 [RFC2440]    Callas, J., et al, "OpenPGP Message Format", RFC 2440,
 608              November 1998.
 609
 610 [RFC2459]    Housley, R., et al, "Internet X.509 Public Key
 611              Infrastructure, Certificate and CRL Profile", RFC 2459,
 612              January 1999.
 613
 614 [SSH-TRANS]  Ylonen, T., et al, "SSH Transport Layer Protocol",
 615              Internet Draft.
 616
 617 [PKCS7]      Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
 618              Version 1.5", RFC 2315, March 1998.
 619
 620
 621 .ti 0
 622 5 Author's Address
 623
 624 Pekka Riikonen
 625 Snellmaninkatu 34 A 15
 626 70100 Kuopio
 627 Finland
 628
 629 EMail: priikone@iki.fi
 630
 631 This Internet-Draft expires 15 November 2002