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