updates.

[website.git] / docs / protocol / draft-riikonen-presence-attrs-04.txt

Network Working Group                                        P. Riikonen
Internet-Draft
draft-riikonen-presence-attrs-04.txt                     15 January 2007
Expires: 15 July 2007


              User Online Presence and Information Attributes
                  <draft-riikonen-presence-attrs-04.txt>

Status of this Draft

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



Abstract

   This document defines set of attributes that can represent the online
   user's presence in a network, and to provide general information about
   the user.  The purpose is to provide a generic mechanism to share
   online presence and status, and general information about the user
   to be used in several kind of network protocols and applications.
   These attributes could be used by for example chat and conferencing
   protocols (such as Instant Message protocols), network games, and
   other similar network protocols and applications that has online
   users in a network.









Riikonen                                                        [Page 1]
\f
Internet Draft                                           15 January 2007


Table of Contents

   1 Introduction ..................................................  2
     1.1 Requirements Terminology ..................................  2
   2 Attributes Concept ............................................  3
     2.1 Requesting Attributes .....................................  3
     2.2 Replying Attributes .......................................  3
     2.3 Attribute Data Types ......................................  4
     2.4 Attribute Payload .........................................  4
     2.5 Attributes ................................................  5
   3 Security Considerations .......................................  12
   4 References ....................................................  12
   5 Author's Address ..............................................  13
   6 Full Copyright Statement ......................................  13


1. Introduction

   This document defines set of attributes that can represent the online
   user's presence in a network, and to provide general information about
   the user.  The purpose is to provide a generic mechanism to share
   online presence and status, and general information about the user
   to be used in several kind of network protocols and applications.
   These attributes could be used by for example chat and conferencing
   protocols (such as Instant Message protocols), network games, and
   other similar network protocols and applications that has online
   users in a network.

   This document does not define these attributes to be used in any
   specific protocol, but assumes that they can be used generally in
   any kind of online network protocol.  Furthermore, the document
   pays attention to special needs of various protocols, such as
   mobile network protocols, which requires the attributes to be
   both robust and compact.  The attributes are also considered to be
   easily implementable and for this reason a clear and robust structure
   was chosen for the attributes.

   This document is strongly influenced by Wireless Village Initiative
   where similar attributes are defined, and credits for the ideas are
   due there.  However, they are defined only in the context of the
   Wireless Village, and the format of the attributes used is not
   suitable for general purpose usage.


1.1 Requirements Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
   MAY, and OPTIONAL, when they appear in this document, are to be



Riikonen                                                        [Page 2]
\f
Internet Draft                                           15 January 2007


   interpreted as described in [RFC2119].


2 Attributes Concept

   Many network protocols needs a way to transfer and retrieve status
   information about users in a network.  For example, many chat and
   conferencing protocols such as IRC, and all Instant Message (IM)
   protocols, such as ICQ has a way to retrieve presence and status
   information about the users in the network.  This could be added to
   several other kind of network protocols as well, and for this reason
   a defined mechanism to provide these informations is needed.

   The attributes are usually requested by an entity in the network
   from other entity, usually a user or end user's device in the network.
   The recipient then replies to each of the requested attributes and
   sends the reply to the requester.

   This document does not define the actual transport for requesting and
   providing the replies to the requests, since this is irrelevant.
   This document defines a payload for requesting, and providing the
   information, but how the payload is transported is not defined in
   this document.  In a client-server network model the user requesting
   attributes usually destine the request to a remote user and the
   server relays the attributes to the remote user.  It is also possible
   that the concept is not user-to-user, but the server replies to the
   requested attributes on behalf of the user.


2.1 Requesting Attributes

   When an entity requests attributes from a user in the network,
   it assembles a list of Attribute Payloads, and sets the requested
   attribute value into the payload.  Each requested attribute is a separate
   Attribute Payload and they MUST be appended one after the other.  The
   requester need to understand that the recipient may not understand all
   the requested attributes, and may not reply to all of the requested
   attributes.  The requester also need to understand that the recipient
   may reply with additional attributes that were not requested.


2.2 Replying Attributes

   When en entity receives the Attribute Payloads it parses them one after
   the other.  The entity can parse each of the Attribute Payload separately
   since it knows the length of the current attribute; next attribute
   begins after the current attribute ends.  The entity then checks the
   requested attribute and SHOULD reply either with valid value or with



Riikonen                                                        [Page 3]
\f
Internet Draft                                           15 January 2007


   an indication that the attribute is unsupported or unknown.  It is
   also possible to reply with additional attributes that were not
   requested.

   When replying to the requested attributes the entity assembles a list
   of Attribute Payloads, each including the attribute type and the
   actual attribute data.


2.3 Attribute Data Types

   This section defines basic data types that can appear in the attributes
   in this document.

   All integer values are stored in the MSB first order.  The size of the
   integer is provided separately with the attribute.  Integer is
   represented as "integer" in this documentation.

   Strings MUST be UTF-8 [RFC2279] encoded, and include 2 bytes length
   field indicating the length of the string.  Hence, when "string" value
   appears in this documentation it is encoded as:

      Length       Type       Value
      2 bytes      integer    Length of String field
      variable     UTF-8      String

   If string is not present then the length field includes zero (0)
   value.

   Boolean value is represented as "boolean" and its size is 1 byte.
   Value 0x00 indicates false value and value 0x01 indicates true value.


2.4 Attribute Payload

   The Attribute Payload is used to request an attribute, and to reply
   to the requested attribute.  One payload includes one attribute.


                          1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Attribute   |   Attr Flags  |        Attribute Length       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                        Attribute Data                         ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Riikonen                                                        [Page 4]
\f
Internet Draft                                           15 January 2007


                       Figure 1:  Attribute Payload


      o Attribute (1 byte) - Indicates the attribute included in this
        Attribute Payload.

      o Attribute Flags (1 byte) - Indicates the flags associated
        with this attribute.  The following flags are defined:

          0x01        ATTRIBUTE_FLAG_INVALID

            The attribute value in Attribute Data is invalid, or
            unknown.  This may be set to indicate that a requested
            attribute is not available, its value is unknown, or
            sender does not understand it.

          0x02        ATTRIBUTE_FLAG_VALID

            The attribute value is included in the Attribute Data.

        When sending this payload to request attributes this value
        MUST be set to zero (0) value.  When sending a reply to the
        request this field MUST NOT include a zero (0) value.

      o Attribute Length (2 bytes) - Indicates the length of the
        Attribute Data field, not including any other field.

      o Attribute Data (variable length) - The Attribute Data.
        The contents of this field is attribute specific, defined
        subsequently.


2.5 Attributes

   The following values can appear in the Attribute field in the
   Attribute Payload to indicate the content of the attribute.  The
   format of the attribute data is represented as length, type and
   value.  Example:

      Length       Type       Value
      2 bytes      integer    Some integer value
      variable     string     Some string
      1 byte       boolean    Boolean value

   When sending multiple Attribute Payloads it is possible to include
   multiple same attributes in the packet.





Riikonen                                                        [Page 5]
\f
Internet Draft                                           15 January 2007


      0    ATTRIBUTE_NONE

           This attribute is reserved and it is never sent.


      1    ATTRIBUTE_USER_INFO

           This attribute includes general information about the user, their
           name and contact information.  The content of this attribute is
           a VCard version 3.0 as defined in RFC 2426 [RFC2426] and RFC 2425
           [RFC2425].  Note that some of the information that VCard provides
           can be also provided in the means of providing other attributes.
           The rationale for this is that the VCard does not provide all the
           information, or with the required precision that may be desired in
           some applications.  It is therefore RECOMMENDED that this attribute
           would be used to provide only basic and constant user information,
           such as name and contact information, but not online status
           information.

           Length       Type       Value
           variable     VCard      Basic user information


      2    ATTRIBUTE_SERVICE

           This attribute indicates a service in the Internet that the user
           is currently using or has logged in.  It also shows when the user
           started using the service, and how long user has been idle in the
           service.  The value of this attribute is as follows:

           Length       Type       Value
           4 bytes      integer    Service Port (IANA specified)
           variable     string     Service Address
           1 byte       boolean    Online status.  If this is set to
                                   0x01 (true) it means the user is online
                                   in the service.  Set to 0x00 (false) when
                                   out of reach.
           variable     string     Signon date and time, UTC date, format as
                                   in ISO 8601
           4 bytes      integer    Idle time


      3    ATTRIBUTE_STATUS_MOOD

           This attribute indicates the mood of the user.  It can indicate
           whether the user is eager to participate in the network.  The
           value of this attribute is as follows:




Riikonen                                                        [Page 6]
\f
Internet Draft                                           15 January 2007


           Length       Type       Value
           4 bytes      integer    Mood mask (values ORed together)

           The following mood values are defined:

           0x00000000   MOOD_NORMAL       No specific mood, normal mood
           0x00000001   MOOD_HAPPY        The user feels happy
           0x00000002   MOOD_SAD          The user feels sad
           0x00000004   MOOD_ANGRY        The user feels angry
           0x00000008   MOOD_JEALOUS      The user feels jealous
           0x00000010   MOOD_ASHAMED      The user feels ashamed
           0x00000020   MOOD_INVINCIBLE   The user feels invincible
           0x00000040   MOOD_INLOVE       The user feels being in love
           0x00000080   MOOD_SLEEPY       The user feels sleepy
           0x00000100   MOOD_BORED        The user feels bored
           0x00000200   MOOD_EXCITED      The user feels excited
           0x00000400   MOOD_ANXIOUS      The user feels anxious


      4    ATTRIBUTE_STATUS_FREETEXT

           This attribute includes the user's online status free text.  It
           can provide personal status as a text message.  The contents of
           this attribute is a UTF-8 encoded free text string.

           Length       Type       Value
           variable     string     Free text status string


      5    ATTRIBUTE_STATUS_MESSAGE

           This attribute includes the user's online status message.  It
           could provide for example a multi media message showing the status
           of the user.  The contents of this attribute is a MIME object,
           which can be used to provide for example video, audio, image or
           other similar status message.  It could also provide a reference
           to the message, for example an URL address.

           Length       Type       Value
           variable     MIME       Status message as MIME object


      6    ATTRIBUTE_PREFERRED_LANGUAGE

           This attribute indicates the preferred language to be used when
           communicating.  The encoding of this attribute is as follows:

           Length       Type       Value



Riikonen                                                        [Page 7]
\f
Internet Draft                                           15 January 2007


           variable     string     ISO 639-2/T three letter code


      7    ATTRIBUTE_PREFERRED_CONTACT

           This attribute indicates the preferred contact methods.  It can
           indicate the method the user prefers when contacting.  The value
           of this attribute is as follows:

           Length       Type       Value
           4 bytes      integer    Contact mask (values ORed together)

           The following contact methods are defined:

           0x00000000   CONTACT_NONE     No specific preferred contact method
           0x00000001   CONTACT_EMAIL    Email is preferred
           0x00000002   CONTACT_CALL     Phone call is preferred
           0x00000004   CONTACT_PAGE     Paging is preferred
           0x00000008   CONTACT_SMS      SMS is preferred
           0x00000010   CONTACT_MMS      MMS is preferred
           0x00000020   CONTACT_CHAT     Chatting is preferred
           0x00000040   CONTACT_VIDEO    Video conferencing is preferred


      8    ATTRIBUTE_TIMEZONE

           This attribute can be used to provide the current local time for
           the user.  The contents of this attribute is a UTF-8 encoded
           string and the format of the string is UTC time zone defined
           in the ISO 8601.

           Length       Type       Value
           variable     string     UTC date, format as in ISO 8601

           Note that ATTRIBUTE_USER_INFO may also provide this information.
           However it is RECOMMENDED that this attribute is used when
           current time zone information is provided.


      9    ATTRIBUTE_GEOLOCATION

           This attribute can be used to provide measured global location of
           the user.  How this information is gathered is out of scope of
           this document.  The attribute can provide latitude and longitude
           lateral positions, but also a vertical position.  A parameter
           describing the accuracy of the information can also be provided.

           Length       Type       Value



Riikonen                                                        [Page 8]
\f
Internet Draft                                           15 January 2007


           variable     string     Longitude (ex. 31 17 14.321W)
           variable     string     Latitude (ex. 12 11 21.2N)
           variable     string     Altitude
           variable     string     Accuracy in meters

           Note that ATTRIBUTE_USER_INFO may also provide this information,
           however it does not have the vertical position, or the accuracy
           parameter.  It is RECOMMENDED that this attribute is used when
           providing current global position information.


      10   ATTRIBUTE_DEVICE_INFO

           This attribute includes information about the user's device.
           The encoding of this attribute is as follows:

           Length       Type       Value
           4 bytes      integer    Device type
           variable     string     Name of the device manufacturer
           variable     string     Device version
           variable     string     Device model
           variable     string     Device language (ISO 639-2/T)

           The following Device types are defined:

           0    DEVICE_COMPUTER        Device is a computer
           1    DEVICE_MOBILE_PHONE    Device is a mobile phone
           2    DEVICE_PDA             Device is a PDA
           3    DEVICE_TERMINAL        Device is a terminal


      11   ATTRIBUTE_EXTENSION

           This attribute indicates that the attribute value is vendor,
           application or service specific attribute extension.  This field
           MUST include a MIME object, which is the extension value.  This
           document does not specify any explicit MIME objects for this
           attribute.

           Length       Type       Value
           variable     MIME       Attribute extension as MIME object


      12   ATTRIBUTE_USER_PUBLIC_KEY

           This attribute includes the user's public key or certificate.
           As the public key and certificate format depends on which sort
           of algorithm or certificate encoding user is using we need to



Riikonen                                                        [Page 9]
\f
Internet Draft                                           15 January 2007


           define a mechanism to differentiate the public key types from
           each other.  This document specifies the most common public keys
           and certificates.  This attribute can be used to deliver the
           user's public key, and it MUST be present if also the
           ATTRIBUTE_USER_DIGITAL_SIGNATURE is present.  Note that the
           recipient of this attribute SHOULD verify the public key from
           a third party, for example from Certification Authority.  If
           there are more than one ATTRIBUTE_USER_PUBLIC_KEY attributes set
           and ATTRIBUTE_USER_DIGITAL_SIGNATURE is also set, the digital
           signature SHOULD be verifiable with the first set public key.

           Length       Type       Value
           variable     string     Public key/certificate type
           variable     data       Public key/certificate data

           The following public key/certificate types are defined:

           ssh-rsa           SSH RSA public key [SSH-TRANS]
           ssh-dss           SSH DSS public key [SSH-TRANS]
           silc-rsa          SILC RSA public key [SILC1]
           silc-dss          SILC DSS public key [SILC1]
           pgp-sign-rsa      OpenPGP RSA certificate [RFC2440]
           pgp-sign-dss      OpenPGP DSS certificate [RFC2440]
           x509v3-sign-rsa   X.509 Version 3 RSA certificate [RFC2459]
           x509v3-sign-dss   X.509 Version 3 DSS certificate [RFC2459]

           Most of these public key/certificate types are equivalent to
           the types specified for SSH protocol [SSH-TRANS] and are expected
           to be officially assigned by IANA.

           The encoding of the public key/certificate data in the attribute
           is done in the manner defined in their respective definitions.

           Note that these public keys are intended for signing.  Some
           certificates may have a key usage restrictions and same key cannot
           be used for both encryption and signing.  Therefore, the name
           of the certificate type indicates if they are intended for
           signing only.


      13   ATTRIBUTE_SERVER_PUBLIC_KEY

           This attribute includes a third party server or authority public
           key or CA certificate and MUST be present if the attribute
           ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also present.  The format
           for this attribute is identical to the ATTRIBUTE_USER_PUBLIC_KEY
           attribute.  If there are more than one ATTRIBUTE_SERVER_PUBLIC_KEY
           attributes set and ATTRIBUTE_SERVER_DIGITAL_SIGNATURE is also set,



Riikonen                                                       [Page 10]
\f
Internet Draft                                           15 January 2007


           the digital signature SHOULD be verifiable with the first set public
           key.


      14   ATTRIBUTE_USER_DIGITAL_SIGNATURE

           This attribute value includes digital signature of all Attribute
           Payloads except this attribute.  This signature can be provided by
           the user.  This attribute SHOULD be last attribute provided in the
           reply so that it is easier for the receiver to compute the signature
           data to be verified.  The format and encoding of this attribute
           depends on the public key or certificate used to produce the
           signature.  See the ATTRIBUTE_USER_PUBLIC_KEY for all public keys
           and certificates that can be used to produce a signature.

           Length       Type       Value
           variable     data       Digital signature data

           The encodings are as follows per public key/certificate type:

           ssh-rsa and ssh-dss                   Defined in [SSH-TRANS]
           silc-rsa and silc-dss                 Defined in [SILC1]
           pgp-sign-rsa and pgp-sign-dss         Defined in [RFC2440]
           x509v3-sign-rsa and x509v3-sign-dss   Defined in [PKCS7]

           The procedure producing the signature and encoding it are done
           in the manner defined in their respective definitions, see the
           provided references.  Also the hash function used with the
           signature procedure is defined by the public key/certificate type.


      15   ATTRIBUTE_SERVER_DIGITAL_SIGNATURE

           This attribute value includes digital signature of all Attribute
           Payloads except this attribute, but including the attribute
           ATTRIBUTE_USER_DIGITAL_SIGNATURE.  This signature can be provided
           by a third party server or an authority which has verified the
           information provided by the user.  How it verifies this information
           is out of scope of this document, however it may base its
           information to a previous registration information and current
           online status of the user in a service.  This attribute SHOULD be
           last when provided, so that it is easier for the receiver to
           compute the signature data to be verified.  The format for this
           attribute is identical to the ATTRIBUTE_USER_DIGITAL_SIGNATURE
           attribute.


      16   ATTRIBUTE_USER_ICON



Riikonen                                                       [Page 11]
\f
Internet Draft                                           15 January 2007


           This attribute includes the user's icon or picture that can be
           associated with the user in the application's user interface.
           The attribute is a MIME object of which content MUST be one of
           the MIME image media types.

           Length       Type       Value
           variable     MIME       Icon as MIME image message


3 Security Considerations

   The use of these attributes dictates whether the attributes need to
   be secured or not.  However, as the attributes are considered to provide
   accurate status information about specific user, it is suggested that
   the attributes would be secured.  The attributes should be digitally
   signed whenever it is possible.  Attributes can also be encrypted
   if it is provided by the protocol using the attributes.  A third party,
   like a server in the network, could also verify the information and provide
   digital signature in case the information is accurate.

   Even though the attributes would be digitally signed by the sender of
   the attributes, the information contained in the attribute may still
   be incorrect.  The third party server should not apply digital signature
   unless it can verify every attribute.  The receiver of the attributes
   should also not trust that the information in fact is correct.

   However, it is possible that the context where these attributes are used
   the attributes are provided by a party that can provide the accurate
   information.  For example a server in the network could reply to the
   attributes on behalf of the actual user for some of the attributes.


4 References

   [RFC2119]    Bradner, S., "Key Words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2279]    Yergeau, F., "UTF-8, a transformation format of ISO
                10646", RFC 2279, January 1998.

   [RFC2425]    Howes, T., et al, "A MIME Content-Type for Directory
                Information", RFC 2425, September 1998.

   [RFC2426]    Dawson, F., et al, "vCard MIME Directory Profile",
                RFC 2426, September 1998.

   [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
                Protocol Specification", Internet Draft, January 2007.



Riikonen                                                       [Page 12]
\f
Internet Draft                                           15 January 2007


   [RFC2440]    Callas, J., et al, "OpenPGP Message Format", RFC 2440,
                November 1998.

   [RFC2459]    Housley, R., et al, "Internet X.509 Public Key
                Infrastructure, Certificate and CRL Profile", RFC 2459,
                January 1999.

   [SSH-TRANS]  Ylonen, T., et al, "SSH Transport Layer Protocol",
                Internet Draft.

   [PKCS7]      Kalinski, B., "PKCS #7: Cryptographic Message Syntax,
                Version 1.5", RFC 2315, March 1998.




5 Author's Address

   Pekka Riikonen
   Helsinki
   Finland

   EMail: priikone@iki.fi


6 Full Copyright Statement

   Copyright (C) The Internet Society (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.











Riikonen                                                       [Page 13]
\f