--- /dev/null
+.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
+<draft-riikonen-presence-attrs-00.txt>
+
+.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
--- /dev/null
+.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
+<draft-riikonen-flags-payloads-00.txt>
+
+.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
projects / crypto.git / commitdiff