X-Git-Url: http://git.silcnet.org/gitweb/?a=blobdiff_plain;f=doc%2Fdraft-riikonen-presence-attrs-03.nroff;fp=doc%2Fdraft-riikonen-presence-attrs-03.nroff;h=0000000000000000000000000000000000000000;hb=72c2de619079457f7a68100eb13385275a424a23;hp=1f83ded57839fc9bb202711b516e58ad9ead3f8e;hpb=e7b6c157b80152bf9fb9266e6bdd93f9fb0db776;p=runtime.git diff --git a/doc/draft-riikonen-presence-attrs-03.nroff b/doc/draft-riikonen-presence-attrs-03.nroff deleted file mode 100644 index 1f83ded5..00000000 --- a/doc/draft-riikonen-presence-attrs-03.nroff +++ /dev/null @@ -1,669 +0,0 @@ -.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 2 February 2004 -.ds CH -.na -.hy 0 -.in 0 -.nf -Network Working Group P. Riikonen -Internet-Draft -draft-riikonen-presence-attrs-03.txt 2 February 2004 -Expires: 2 August 2004 - -.in 3 - -.ce 2 -User Online Presence and Information Attributes - - -.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 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: - -.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. -