From: Pekka Riikonen Date: Mon, 9 Sep 2002 07:25:57 +0000 (+0000) Subject: Added. X-Git-Tag: silc.server.0.9.5~10 X-Git-Url: http://git.silcnet.org/gitweb/?p=silc.git;a=commitdiff_plain;h=88898e7093da46e50881025bffc5e51908624d49 Added. --- diff --git a/doc/draft-riikonen-presence-attrs-01.nroff b/doc/draft-riikonen-presence-attrs-01.nroff new file mode 100644 index 00000000..90f4dfb8 --- /dev/null +++ b/doc/draft-riikonen-presence-attrs-01.nroff @@ -0,0 +1,625 @@ +.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 15 May 2002 +.ds CH +.na +.hy 0 +.in 0 +.nf +Network Working Group P. Riikonen +Internet-Draft +draft-riikonen-presence-attrs-00.txt 15 May 2002 +Expires: 15 November 2002 + +.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 .............................................. 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 +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 +.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. 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. + + +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 + + +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 + + +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 + 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 + 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. + + 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. + + +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. + + +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 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 +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 + +This Internet-Draft expires 15 November 2002 diff --git a/doc/draft-riikonen-silc-flags-payloads-01.nroff b/doc/draft-riikonen-silc-flags-payloads-01.nroff new file mode 100644 index 00000000..fb9d84b6 --- /dev/null +++ b/doc/draft-riikonen-silc-flags-payloads-01.nroff @@ -0,0 +1,304 @@ +.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 15 May 2002 +.ds CH +.na +.hy 0 +.in 0 +.nf +Network Working Group P. Riikonen +Internet-Draft +draft-riikonen-flags-payloads-00.txt 15 May 2002 +Expires: 15 November 2002 + +.in 3 + +.ce 2 +SILC Message Flag Payloads + + +.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 memo describes the data payloads associated with the SILC Message +Flags, as defined in the SILC Packet Protocol Internet Draft [SILC2]. The +purpose of the Message Flags is to augment the function of the Private +Message Payload and Channel Message Payload by allowing the sender to +tell the receiver what type of data the payload includes, and how the +data should be processed. Some of the Message Flags may define additional +payloads to be associated with the flag, and this memo describes these +payloads. + + + + + + + + +.ti 0 +Table of Contents + +.nf +1 Introduction .................................................. 2 + 1.1 Requirements Terminology .................................. 2 +2 SILC Message Flags ............................................ 2 +3 SILC Message Flag Payloads .................................... 3 + 3.1 SILC_MESSAGE_FLAG_REQUEST ................................. 3 + 3.2 SILC_MESSAGE_FLAG_REPLY ................................... 3 + 3.3 SILC_MESSAGE_FLAG_SIGNED .................................. 4 + 3.4 SILC_MESSAGE_FLAG_DATA .................................... 4 +4 Security Considerations ....................................... 5 +5 References .................................................... 5 +6 Author's Address .............................................. 6 + + +.ti 0 +1. Introduction + +The Secure Internet Live Conferencing [SILC1] supports sending binary +messages between users in the network. To make the data sending, and +processing at the receiver's end as simple as possible the SILC defines +Message Flags to the Private Message Payload and Channel Message Payload +[SILC2], which can help the receiver to decide how the data is encoded, +and how it should be interpreted. Some of the Message Flags may define +additional payloads to be associated with the flag, but the [SILC2] does +not define them. This memo defines the payloads for those Message Flags +that was marked to include additional payloads in [SILC2]. + +By defining the payloads for the Message Flags the SILC message payloads +can be augmented to support any kind of data, which can be easily +interpreted at the receiver end. For example, it would be possible to +send audio stream, video stream, image files and HTML pages as messages, +and the receiver can either choose to ignore the message or to process +it, or to perhaps pass the message to some application for processing. +Without specific payloads for Message Flags it is almost impossible for +the receiver to interpret binary data from the payload. + + +.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 SILC Message Flags + +The Message Flags was added to the SILC protocol for the reason that SILC +provides sending binary data as messages between users, and entities in +the network, and interpreting pure binary data is almost impossible. +With the flags the purpose, the reason, and the way the message is +supposed to be interpreted can be told to the recipient. Other +conferencing protocols which are usually ASCII based protocols do not have +such problems since they do not generally support sending of binary data +at all, or require encoding of the data before it can be sent over the +network. + +SILC Private Message Payload and Channel Message Payload can have flags +that can augment the function of the payload. The flags can tell for +example that the message is a request, or a reply to an earlier received +request. They can tell that the message is some action that the sender +is performing, or they can tell that the message is an auto reply, or +that it is explicitly digitally signed by the sender. + +The problem of Message Flags is that the space for flags mask is only 16 +bits, so there is a limited number of flags available. For this reason a +flag that defines some generic way of sending any kind of data as a +message, and that it can be easily interpreted at the receiver's end is +important. For this reason the flag SILC_MESSAGE_FLAG_DATA was added to +the protocol which can represent any data. This memo describe how this +flag is used and how the associated payload is constructed and processed. +This memo also describes payloads for all the other flags that can have +associated payloads. + + +.ti 0 +3 SILC Message Flag Payloads + +The [SILC2] defines the flags which may have associated payloads. This +section will list these flags and define the payloads. + + +.ti 0 +3.1 SILC_MESSAGE_FLAG_REQUEST + +Currently this flag can be used in the context of application specific, +service specific or vendor specific requests, and the data payload type is +dependent of this context. Therefore, payload is not defined for this +flag in this memo. This flag may also be masked with some other flag in +the message payload, including with some other flag that defines +additional payload. + + +.ti 0 +3.2 SILC_MESSAGE_FLAG_REPLY + +Currently this flag can be used in the context of application specific, +service specific or vendor specific replies, and the data payload type is +dependent of this context. Therefore, payload is not defined for this +flag in this memo. This flag may also be masked with some other flag in +the message payload, including with some other flag that defines +additional payload. + + +.ti 0 +3.3 SILC_MESSAGE_FLAG_SIGNED + +Not defined yet. + + +.ti 0 +3.4 SILC_MESSAGE_FLAG_DATA + +This flag is used to represent any data as a message in the way that it +can be easily interpreted by the recipient. This flag is used to send +MIME objects as messages from the sender to the receiver. The MIME as +defined in [RFC2045], [RFC2046], [RFC2047], [RFC2048] and [RFC2049] is +well established protocol for sending different kind of data with many +applications and protocols. It support dozens of different media types +and encodings, and for this reason is ideal for sending data in SILC +message payloads as well. + +When the receiver has checked that the message payload includes the +SILC_MESSAGE_FLAG_DATA flag, it may then start parsing the MIME header. +It would also be possible to pass the message to some application which +can already interpret MIME objects. If the receiver does not support the +media type received in the MIME header, it SHOULD be treated as +"application/octet-stream". The receiver MAY also ignore and discard +messages that it does not support. + +The MIME header MUST be at the start of the data area of the Private +Message Payload or Channel Message Payload. The MIME header received in +the data area of the payload SHOULD have the MIME-Version field at first +and then Content-Type field. The MIME-Version field is not required to be +present in each body part of multipart entity. Additionally the header +MAY also include any other MIME compliant headers. The character encoding +for the MIME Header strings inside the message payload is US-ASCII, as +defined in [RFC2045]. The actual MIME object may define additional +character sets or encodings for the data it delivers. + +Hence, the MIME Header in the message payload may be as follows: + +.in 8 +.nf +MIME-Version: 1.0\\r\\n +Content-Type: discrete/composite\\r\\n +Content-Transfer-Encoding: binary\\r\\n +\\r\\n +.in 3 + +The Content-Transfer-Encoding field behaves as defined in [RFC2045] and +defines the encoding of the data in the MIME object. The preferred data +encoding with SILC is "binary". However, many MIME media types defines +their preferred encoding and they may be used if binary encoding is not +suitable. + +When sending large amounts of traffic or large files as MIME objects the +limits of the SILC Packet needs to be taken into consideration. The +maximum length of SILC Packet is 2^16 bytes, and larger messages would +need to be fragmented. MIME provides way of fragmenting and reassembling +messages, and it is to be done with SILC as defined in [RFC2046]. The +MIME fragmentation is defined for gateway usage, but in case of SILC the +sender may also start sending fragmented MIME objects. + +This flag SHOULD NOT be masked with some other Message Flag that defines +payloads. Generally this sort of setting would be impossible for the +receiver to interpret. However, flags that does not define any specific +payloads MAY be masked with this flag as well. For example, this flag +could be masked also with SILC_MESSAGE_FLAG_REQUEST flag. + + +.ti 0 +4 Security Considerations + +In case of SILC_MESSAGE_FLAG_DATA the implementors should pay special +attention to the security implications of any media type that can cause +the remote execution of any actions in the receiver's environment. The +[RFC2046] and [RFC2048] discusses more MIME specific security +considerations. Even though SILC provides secured messages, in case of +MIME which can be used to transfer files and documents which are stored in +the receiver's local environment, securing separately the MIME object may +be desired. For example, augmenting the MIME support in SILC messages to +support S/MIME may be desired in some implementations. + + + +.ti 0 +5 References + +[SILC1] Riikonen, P., "Secure Internet Live Conferencing (SILC), + Protocol Specification", Internet Draft, May 2002. + +[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft, + May 2002. + +[RFC2045] Freed, N., et al., "Multipurpose Internet Mail Extensions + (MIME) Part One: Format of Internet Message Bodies", + Standards Track, RFC 2045, November 1996. + +[RFC2046] Freed, N., et al., "Multipurpose Internet Mail Extensions + (MIME) Part Two: Media Types", Standards Track, RFC 2045, + November 1996. + +[RFC2047] Moore K., "MIME (Multipurpose Internet Mail Extensions) + Part Three: Message Header Extensions for Non-ASCII Text" + Standards Track, RFC 2047, November 1996. + +[RFC2048] Freed, N., et al., "Multipurpose Internet Mail Extensions + (MIME) Part Four: Registration Procedures", Standards + Track, RFC 2048, November 1996. + +[RFC2049] Freed, N., et al., "Multipurpose Internet Mail Extensions + (MIME) Part Five: Conformance Criteria and Examples", + Standards Track, RFC 2049, November 1996. + +[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + +.ti 0 +6 Author's Address + +Pekka Riikonen +Snellmaninkatu 34 A 15 +70100 Kuopio +Finland + +EMail: priikone@iki.fi + +This Internet-Draft expires 15 November 2002