From 5a90d108fad75b5ee72fb79f97b2b681feb5b57c Mon Sep 17 00:00:00 2001 From: Pekka Riikonen Date: Tue, 14 May 2002 16:29:09 +0000 Subject: [PATCH] updates. --- CHANGES | 4 + doc/draft-riikonen-presence-attrs-00.nroff | 179 ++++++++++----------- 2 files changed, 91 insertions(+), 92 deletions(-) diff --git a/CHANGES b/CHANGES index 1d0a8464..cf3d67ae 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,7 @@ +Tue May 14 19:37:48 EEST 2002 Pekka Riikonen + + * Completed the protocol specifications. + Tue May 7 20:41:58 EEST 2002 Pekka Riikonen * Merged with Irssi CVS for Irssi SILC client. diff --git a/doc/draft-riikonen-presence-attrs-00.nroff b/doc/draft-riikonen-presence-attrs-00.nroff index d309bbc6..811ec637 100644 --- a/doc/draft-riikonen-presence-attrs-00.nroff +++ b/doc/draft-riikonen-presence-attrs-00.nroff @@ -21,7 +21,7 @@ Expires: 15 November 2002 .in 3 -.ce 3 +.ce 2 User Online Presence and Information Attributes @@ -71,17 +71,17 @@ users in a network. 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 @@ -107,9 +107,10 @@ 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. 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 @@ -141,8 +142,10 @@ 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 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 @@ -161,16 +164,16 @@ may reply with additional attributes that were not requested. .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. @@ -254,6 +257,7 @@ o Attribute Length (2 bytes) - Indicates the length of the o Attribute Data (variable length) - The Attribute Data. The contents of this field is attribute specific, defined subsequently. +.in 3 .ti 0 @@ -325,64 +329,18 @@ multiple same attributes in the packet. 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 @@ -408,18 +366,36 @@ multiple same attributes in the packet. 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 @@ -434,7 +410,7 @@ multiple same attributes in the packet. 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 @@ -454,9 +430,9 @@ multiple same attributes in the packet. 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 @@ -474,7 +450,7 @@ multiple same attributes in the packet. 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 @@ -486,7 +462,7 @@ multiple same attributes in the packet. 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 @@ -528,7 +504,7 @@ multiple same attributes in the packet. 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 @@ -537,7 +513,7 @@ multiple same attributes in the packet. 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 @@ -571,7 +547,7 @@ multiple same attributes in the packet. 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 @@ -583,6 +559,25 @@ multiple same attributes in the packet. .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 -- 2.24.0