Merged silc_1_0_branch to trunk.

[silc.git] / doc / draft-riikonen-presence-attrs-02.nroff

.pl 10.0i
.po 0
.ll 7.2i
.lt 7.2i
.nr LL 7.2i
.nr LT 7.2i
.ds LF Riikonen
.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
.ds RH 29 July 2003
.ds CH
.na
.hy 0
.in 0
.nf
Network Working Group                                        P. Riikonen
Internet-Draft
draft-riikonen-presence-attrs-02.txt                        29 July 2003
Expires: 29 January 2004

.in 3

.ce 2
User Online Presence and Information Attributes
<draft-riikonen-presence-attrs-02.txt>

.ti 0
Status of this Memo

This document is an Internet-Draft and is in full conformance with   
all provisions of Section 10 of RFC 2026.  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/ietf/1id-abstracts.txt   

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

The distribution of this memo is unlimited.  


.ti 0
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.







.ti 0
Table of Contents

.nf
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 .......................................  11
4 References ....................................................  12
5 Author's Address ..............................................  13
6 Full Copyright Statement ......................................  13


.ti 0
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.


.ti 0
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
interpreted as described in [RFC2119].


.ti 0
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.


.ti 0
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.


.ti 0
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
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.


.ti 0
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 are always 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:

.in 6
Length       Type       Value
2 bytes      integer    Length of String field
variable     UTF-8      String
.in 3

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.


.ti 0
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.


.in 5
.nf
                     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                         ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.in 3

.ce
Figure 1:  Attribute Payload


.in 6
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.
.in 3


.ti 0
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:

.in 6
Length       Type       Value
2 bytes      integer    Some integer value
variable     string     Some string
1 byte       boolean    Boolean value
.in 3

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


.in 6
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:

     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
     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
     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
     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,
     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.
.in 3


.ti 0
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.


.ti 0
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, May 2002.

[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.




.ti 0
5 Author's Address

Pekka Riikonen
Snellmaninkatu 34 A 15
70100 Kuopio
Finland

EMail: priikone@iki.fi


.ti 0
6 Full Copyright Statement

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.