+.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 XXX
+.ds CH
+.na
+.hy 0
+.in 0
+.nf
+Network Working Group P. Riikonen
+Internet-Draft
+draft-riikonen-flags-payloads-00.txt XXX
+Expires: XXX
+
+.in 3
+
+.ce 3
+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 .................................................. x
+ 1.1 Requirements Terminology .................................. x
+2 SILC Message Flags ............................................ x
+3 SILC Message Flag Payloads .................................... x
+ 3.1 SILC_MESSAGE_FLAG_REQUEST ................................. x
+ 3.2 SILC_MESSAGE_FLAG_REPLY ................................... x
+ 3.3 SILC_MESSAGE_FLAG_SIGNED .................................. x
+ 3.4 SILC_MESSAGE_FLAG_DATA .................................... x
+4 Security Considerations ....................................... x
+5 References .................................................... x
+6 Author's Address .............................................. x
+
+
+.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 [SILC1].
+
+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 desribes 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
+Content-Type: discrete/composite
+Content-Transfer-Encoding: binary
+.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, April 2001.
+
+[SILC2] Riikonen, P., "SILC Packet Protocol", Internet Draft,
+ April 2001.
+
+[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
+Snellmanninkatu 34 A 15
+70100 Kuopio
+Finland
+
+EMail: priikone@iki.fi
+
+This Internet-Draft expires XXX
projects / silc.git / commitdiff