.in 3
-.ce 3
+.ce 2
User Online Presence and Information Attributes
<draft-riikonen-presence-attrs-00.txt>
Table of Contents
.nf
-1 Introduction .................................................. x
- 1.1 Requirements Terminology .................................. x
-2 Attributes Concept ............................................ x
- 2.1 Requesting Attributes ..................................... x
- 2.2 Replying Attributes ....................................... x
- 2.3 Attribute Data Types ...................................... x
- 2.4 Attribute Payload ......................................... x
- 2.5 Attributes ................................................ x
-3 Security Considerations ....................................... x
-4 References .................................................... x
-5 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
was chosen for the attributes.
This document is strongly influenced by Wireless Village Initiative
-where similar attributes are defined. 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.
+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
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 destines the request to a remote user and the
-server relays the attributes to the remote user.
+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
.ti 0
2.2 Replying Attributes
-When user receives the Attribute Payloads it parses them one after
-the other. The user can parse each of the Attribute Payload separately
+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 user then checks the
+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 user assembles a list
+When replying to the requested attributes the entity assembles a list
of Attribute Payloads, each including the attribute type and the
actual attribute data.
o Attribute Data (variable length) - The Attribute Data.
The contents of this field is attribute specific, defined
subsequently.
+.in 3
.ti 0
The following mood values are defined:
- 0x00000000 MOOD_NORMAL
-
- No specific mood, the normal mood for a user.
-
-
- 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.
+ 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
4 ATTRIBUTE_STATUS_FREETEXT
variable MIME Status message as MIME object
-6 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
-7 ATTRIBUTE_PREFERRED_LANGUAGE
+ 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:
-8 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
-9 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.
-10 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
providing current global position information.
-11 ATTRIBUTE_DEVICE_INFO
+10 ATTRIBUTE_DEVICE_INFO
- This attribute includes information about the user's device
+ This attribute includes information about the user's device.
The encoding of this attribute is as follows:
Length Type Value
3 DEVICE_TERMINAL Device is a terminal
-12 ATTRIBUTE_EXTENSION
+11 ATTRIBUTE_EXTENSION
This attribute indicates that the attribute value is vendor,
application or service specific attribute extension. This field
variable MIME Attribute extension as MIME object
-13 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
signing only.
-14 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.
-15 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
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
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
projects / silc.git / commitdiff