.ds RF FORMFEED[Page %]
.ds CF
.ds LH Internet Draft
-.ds RH XXX
+.ds RH 15 May 2002
.ds CH
.na
.hy 0
.nf
Network Working Group P. Riikonen
Internet-Draft
-draft-riikonen-presence-attrs-00.txt XXX
-Expires: XXX
+draft-riikonen-presence-attrs-00.txt 15 May 2002
+Expires: 15 November 2002
.in 3
-.ce 3
+.ce 2
User Online Presence and Information Attributes
<draft-riikonen-presence-attrs-00.txt>
.ti 0
Abstract
-ZZZ
+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.
Table of Contents
.nf
-1 Introduction .................................................. x
- 1.1 Requirements Terminology .................................. x
-
-4 Security Considerations ....................................... x
-5 References .................................................... x
-6 Author's Address .............................................. x
+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 .............................................. 12
.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
-X.X Attribute Payload
+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
o Attribute Data (variable length) - The Attribute Data.
The contents of this field is attribute specific, defined
subsequently.
+.in 3
.ti 0
-X.X Attributes
+2.5 Attributes
The following values can appear in the Attribute field in the
-Attribute Payload to indicate the content of the attribute. All
-integer values are stored in the MSB first order. 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.
-
-The format of the attribute data is represented as length, type and
+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
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 2425 [RFC2425] and RFC 2426
- [RFC2426]. Note that some of the information that VCard provides
+ 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
out of reach.
-x ATTRIBUTE_STATUS_MOOD
+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 exited
+ 0x00000400 MOOD_ANXIOUS The user feels anxious
-x ATTRIBUTE_STATUS_FREETEXT
+
+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
variable string Free text status string
-x ATTRIBUTE_STATUS_MESSAGE
+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
variable MIME Status message as MIME object
-x ATTRIBUTE_STATUS_COMMUNICATION
+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:
-x ATTRIBUTE_PREFERRED_LANGUAGE
+ Length Type Value
+ 4 bytes integer Contact mask (values ORed together)
+ The following contact methods are defined:
-x ATTRIBUTE_PREFERRED_CONTACT
+ 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
-x ATTRIBUTE_TIMEZONE
+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
current time zone information is provided.
-x ATTRIBUTE_GEOLOCATION
+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
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
+ variable string Latitude
+ 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
providing current global position information.
-x ATTRIBUTE_DEVICE_INFO
+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)
-x ATTRIBUTE_EXTENSION
+ 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 MIME object, which is the extension value. This
+ MUST include a MIME object, which is the extension value. This
document does not specify any explicit MIME objects for this
attribute.
variable MIME Attribute extension as MIME object
-x ATTRIBUTE_USER_PUBLIC_KEY
+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
x509v3-sign-rsa X.509 Version 3 RSA certificate [RFC2459]
x509v3-sign-dss X.509 Version 3 DSS certificate [RFC2459]
- 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 silc-rsa and silc-dss are not
- currently specified in SSH, however they are considered to be
- IANA assigned later anyway.
+ 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 that they are intended for
- signing.
+ of the certificate type indicates if they are intended for
+ signing only.
-x ATTRIBUTE_SERVER_PUBLIC_KEY
+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.
-x ATTRIBUTE_USER_DIGITAL_SIGNATURE
+14 ATTRIBUTE_USER_DIGITAL_SIGNATURE
This attribute value includes digital signature of all Attribute
Payloads except this attribute. This signature can be provided by
provided references.
-x ATTRIBUTE_SERVER_DIGITAL_SIGNATURE
+15 ATTRIBUTE_SERVER_DIGITAL_SIGNATURE
This attribute value includes digital signature of all Attribute
Payloads except this attribute, but including the attribute
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 registeration information and current
+ 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
.ti 0
-4 Security Considerations
+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 infact 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
-5 References
+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
-6 Author's Address
+5 Author's Address
Pekka Riikonen
-Snellmanninkatu 34 A 15
+Snellmaninkatu 34 A 15
70100 Kuopio
Finland
EMail: priikone@iki.fi
-This Internet-Draft expires XXX
+This Internet-Draft expires 15 November 2002
projects / silc.git / blobdiff