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 25 November 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-01.txt                    25 November 2002
  20 Expires: 25 April 2003
  21
  22 .in 3
  23
  24 .ce 2
  25 User Online Presence and Information Attributes
  26 <draft-riikonen-presence-attrs-01.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
  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.  It also shows when the user
 310      started using the service, and how long user has been idle in the
 311      service.  The value of this attribute is as follows:
 312
 313      Length       Type       Value
 314      4 bytes      integer    Service Port (IANA specified)
 315      variable     string     Service Address
 316      1 byte       boolean    Online status.  If this is set to
 317                              0x01 (true) it means the user is online
 318                              in the service.  Set to 0x00 (false) when
 319                              out of reach.
 320      variable     string     Signon date and time, UTC date, format as
 321                              in ISO 8601
 322      4 bytes      integer    Idle time
 323
 324
 325 3    ATTRIBUTE_STATUS_MOOD
 326
 327      This attribute indicates the mood of the user.  It can indicate
 328      whether the user is eager to participate in the network.  The
 329      value of this attribute is as follows:
 330
 331      Length       Type       Value
 332      4 bytes      integer    Mood mask (values ORed together)
 333
 334      The following mood values are defined:
 335
 336      0x00000000   MOOD_NORMAL       No specific mood, normal mood
 337      0x00000001   MOOD_HAPPY        The user feels happy
 338      0x00000002   MOOD_SAD          The user feels sad
 339      0x00000004   MOOD_ANGRY        The user feels angry
 340      0x00000008   MOOD_JEALOUS      The user feels jealous
 341      0x00000010   MOOD_ASHAMED      The user feels ashamed
 342      0x00000020   MOOD_INVINCIBLE   The user feels invincible
 343      0x00000040   MOOD_INLOVE       The user feels being in love
 344      0x00000080   MOOD_SLEEPY       The user feels sleepy
 345      0x00000100   MOOD_BORED        The user feels bored
 346      0x00000200   MOOD_EXCITED      The user feels excited
 347      0x00000400   MOOD_ANXIOUS      The user feels anxious
 348
 349
 350 4    ATTRIBUTE_STATUS_FREETEXT
 351
 352      This attribute includes the user's online status free text.  It
 353      can provide personal status as a text message.  The contents of
 354      this attribute is a UTF-8 encoded free text string.
 355
 356      Length       Type       Value
 357      variable     string     Free text status string
 358
 359
 360 5    ATTRIBUTE_STATUS_MESSAGE
 361
 362      This attribute includes the user's online status message.  It
 363      could provide for example a multi media message showing the status
 364      of the user.  The contents of this attribute is a MIME object,
 365      which can be used to provide for example video, audio, image or
 366      other similar status message.  It could also provide a reference
 367      to the message, for example an URL address.
 368
 369      Length       Type       Value
 370      variable     MIME       Status message as MIME object
 371
 372
 373 6    ATTRIBUTE_PREFERRED_LANGUAGE
 374
 375      This attribute indicates the preferred language to be used when
 376      communicating.  The encoding of this attribute is as follows:
 377
 378      Length       Type       Value
 379      variable     string     ISO 639-2/T three letter code
 380
 381
 382 7    ATTRIBUTE_PREFERRED_CONTACT
 383
 384      This attribute indicates the preferred contact methods.  It can
 385      indicate the method the user prefers when contacting.  The value
 386      of this attribute is as follows:
 387
 388      Length       Type       Value
 389      4 bytes      integer    Contact mask (values ORed together)
 390
 391      The following contact methods are defined:
 392
 393      0x00000000   CONTACT_NONE     No specific preferred contact method
 394      0x00000001   CONTACT_EMAIL    Email is preferred
 395      0x00000002   CONTACT_CALL     Phone call is preferred
 396      0x00000004   CONTACT_PAGE     Paging is preferred
 397      0x00000008   CONTACT_SMS      SMS is preferred
 398      0x00000010   CONTACT_MMS      MMS is preferred
 399      0x00000020   CONTACT_CHAT     Chatting is preferred
 400
 401
 402 8    ATTRIBUTE_TIMEZONE
 403
 404      This attribute can be used to provide the current local time for
 405      the user.  The contents of this attribute is a UTF-8 encoded
 406      string and the format of the string is UTC time zone defined
 407      in the ISO 8601.
 408
 409      Length       Type       Value
 410      variable     string     UTC date, format as in ISO 8601
 411
 412      Note that ATTRIBUTE_USER_INFO may also provide this information.
 413      However it is RECOMMENDED that this attribute is used when
 414      current time zone information is provided.
 415
 416
 417 9    ATTRIBUTE_GEOLOCATION
 418
 419      This attribute can be used to provide measured global location of
 420      the user.  How this information is gathered is out of scope of
 421      this document.  The attribute can provide latitude and longitude
 422      lateral positions, but also a vertical position.  A parameter
 423      describing the accuracy of the information can also be provided.
 424
 425      Length       Type       Value
 426      variable     string     Longitude (ex. 31 17 14.321W)
 427      variable     string     Latitude (ex. 12 11 21.2N)
 428      variable     string     Altitude
 429      variable     string     Accuracy in meters
 430
 431      Note that ATTRIBUTE_USER_INFO may also provide this information,
 432      however it does not have the vertical position, or the accuracy
 433      parameter.  It is RECOMMENDED that this attribute is used when
 434      providing current global position information.
 435
 436
 437 10   ATTRIBUTE_DEVICE_INFO
 438
 439      This attribute includes information about the user's device.
 440      The encoding of this attribute is as follows:
 441
 442      Length       Type       Value
 443      4 bytes      integer    Device type
 444      variable     string     Name of the device manufacturer
 445      variable     string     Device version
 446      variable     string     Device model
 447      variable     string     Device language (ISO 639-2/T)
 448
 449      The following Device types are defined:
 450
 451      0    DEVICE_COMPUTER        Device is a computer
 452      1    DEVICE_MOBILE_PHONE    Device is a mobile phone
 453      2    DEVICE_PDA             Device is a PDA
 454      3    DEVICE_TERMINAL        Device is a terminal
 455
 456
 457 11   ATTRIBUTE_EXTENSION
 458
 459      This attribute indicates that the attribute value is vendor,
 460      application or service specific attribute extension.  This field
 461      MUST include a MIME object, which is the extension value.  This
 462      document does not specify any explicit MIME objects for this
 463      attribute.
 464
 465      Length       Type       Value
 466      variable     MIME       Attribute extension as MIME object
 467
 468
 469 12   ATTRIBUTE_USER_PUBLIC_KEY
 470
 471      This attribute includes the user's public key or certificate.
 472      As the public key and certificate format depends on which sort
 473      of algorithm or certificate encoding user is using we need to
 474      define a mechanism to differentiate the public key types from
 475      each other.  This document specifies the most common public keys
 476      and certificates.  This attribute can be used to deliver the
 477      user's public key, and it MUST be present if also the
 478      ATTRIBUTE_USER_DIGITAL_SIGNATURE is present.  Note that the
 479      recipient of this attribute SHOULD verify the public key from
 480      a third party, for example from Certification Authority.  If
 481      there are more than one ATTRIBUTE_USER_PUBLIC_KEY attributes set
 482      and ATTRIBUTE_USER_DIGITAL_SIGNATURE is also set, the digital
 483      signature SHOULD be verifiable with the first set public key.
 484
 485      Length       Type       Value
 486      variable     string     Public key/certificate type
 487      variable     data       Public key/certificate data
 488
 489      The following public key/certificate types are defined:
 490
 491      ssh-rsa           SSH RSA public key [SSH-TRANS]
 492      ssh-dss           SSH DSS public key [SSH-TRANS]
 493      silc-rsa          SILC RSA public key [SILC1]
 494      silc-dss          SILC DSS public key [SILC1]
 495      pgp-sign-rsa      OpenPGP RSA certificate [RFC2440]
 496      pgp-sign-dss      OpenPGP DSS certificate [RFC2440]
 497      x509v3-sign-rsa   X.509 Version 3 RSA certificate [RFC2459]
 498      x509v3-sign-dss   X.509 Version 3 DSS certificate [RFC2459]
 499
 500      Most of these public key/certificate types are equivalent to
 501      the types specified for SSH protocol [SSH-TRANS] and are expected
 502      to be officially assigned by IANA.
 503
 504      The encoding of the public key/certificate data in the attribute
 505      is done in the manner defined in their respective definitions.
 506
 507      Note that these public keys are intended for signing.  Some
 508      certificates may have a key usage restrictions and same key cannot
 509      be used for both encryption and signing.  Therefore, the name
 510      of the certificate type indicates if they are intended for
 511      signing only.
 512
 513
 514 13   ATTRIBUTE_SERVER_PUBLIC_KEY
 515
 516      This attribute includes a third party server or authority public
 517      key or CA certificate and MUST be present if the attribute
 518      ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also present.  The format
 519      for this attribute is identical to the ATTRIBUTE_USER_PUBLIC_KEY
 520      attribute.  If there are more than one ATTRIBUTE_SERVER_PUBLIC_KEY
 521      attributes set and ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also set,
 522      the digital signature SHOULD be verifiable with the first set public
 523      key.
 524
 525
 526 14   ATTRIBUTE_USER_DIGITAL_SIGNATURE
 527
 528      This attribute value includes digital signature of all Attribute
 529      Payloads except this attribute.  This signature can be provided by
 530      the user.  This attribute SHOULD be last attribute provided in the
 531      reply so that it is easier for the receiver to compute the signature
 532      data to be verified.  The format and encoding of this attribute
 533      depends on the public key or certificate used to produce the
 534      signature.  See the ATTRIBUTE_USER_PUBLIC_KEY for all public keys
 535      and certificates that can be used to produce a signature.
 536
 537      Length       Type       Value
 538      variable     data       Digital signature data
 539
 540      The encodings are as follows per public key/certificate type:
 541
 542      ssh-rsa and ssh-dss                   Defined in [SSH-TRANS]
 543      silc-rsa and silc-dss                 Defined in [SILC1]
 544      pgp-sign-rsa and pgp-sign-dss         Defined in [RFC2440]
 545      x509v3-sign-rsa and x509v3-sign-dss   Defined in [PKCS7]
 546
 547      The procedure producing the signature and encoding it are done
 548      in the manner defined in their respective definitions, see the
 549      provided references.  Also the hash function used with the
 550      signature procedure is defined by the public key/certificate type.
 551
 552
 553 15   ATTRIBUTE_SERVER_DIGITAL_SIGNATURE
 554
 555      This attribute value includes digital signature of all Attribute
 556      Payloads except this attribute, but including the attribute
 557      ATTRIBUTE_USER_DIGITAL_SIGNATURE.  This signature can be provided
 558      by a third party server or an authority which has verified the
 559      information provided by the user.  How it verifies this information
 560      is out of scope of this document, however it may base its
 561      information to a previous registration information and current
 562      online status of the user in a service.  This attribute SHOULD be
 563      last when provided, so that it is easier for the receiver to
 564      compute the signature data to be verified.  The format for this
 565      attribute is identical to the ATTRIBUTE_USER_DIGITAL_SIGNATURE
 566      attribute.
 567 .in 3
 568
 569
 570 .ti 0
 571 3 Security Considerations
 572
 573 The use of these attributes dictates whether the attributes need to
 574 be secured or not.  However, as the attributes are considered to provide
 575 accurate status information about specific user, it is suggested that
 576 the attributes would be secured.  The attributes should be digitally
 577 signed whenever it is possible.  Attributes can also be encrypted
 578 if it is provided by the protocol using the attributes.  A third party,
 579 like a server in the network, could also verify the information and provide
 580 digital signature in case the information is accurate.
 581
 582 Even though the attributes would be digitally signed by the sender of
 583 the attributes, the information contained in the attribute may still
 584 be incorrect.  The third party server should not apply digital signature
 585 unless it can verify every attribute.  The receiver of the attributes
 586 should also not trust that the information in fact is correct.
 587
 588 However, it is possible that the context where these attributes are used
 589 the attributes are provided by a party that can provide the accurate
 590 information.  For example a server in the network could reply to the
 591 attributes on behalf of the actual user for some of the attributes.
 592
 593
 594 .ti 0
 595 4 References
 596
 597 [RFC2119]    Bradner, S., "Key Words for use in RFCs to Indicate
 598              Requirement Levels", BCP 14, RFC 2119, March 1997.
 599
 600 [RFC2279]    Yergeau, F., "UTF-8, a transformation format of ISO
 601              10646", RFC 2279, January 1998.
 602
 603 [RFC2425]    Howes, T., et al, "A MIME Content-Type for Directory
 604              Information", RFC 2425, September 1998.
 605
 606 [RFC2426]    Dawson, F., et al, "vCard MIME Directory Profile",
 607              RFC 2426, September 1998.
 608
 609 [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
 610              Protocol Specification", Internet Draft, May 2002.
 611
 612 [RFC2440]    Callas, J., et al, "OpenPGP Message Format", RFC 2440,
 613              November 1998.
 614
 615 [RFC2459]    Housley, R., et al, "Internet X.509 Public Key
 616              Infrastructure, Certificate and CRL Profile", RFC 2459,
 617              January 1999.
 618
 619 [SSH-TRANS]  Ylonen, T., et al, "SSH Transport Layer Protocol",
 620              Internet Draft.
 621
 622 [PKCS7]      Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
 623              Version 1.5", RFC 2315, March 1998.
 624
 625
 626
 627
 628 .ti 0
 629 5 Author's Address
 630
 631 Pekka Riikonen
 632 Snellmaninkatu 34 A 15
 633 70100 Kuopio
 634 Finland
 635
 636 EMail: priikone@iki.fi
 637
 638 This Internet-Draft expires 25 April 2003