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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
