doc/draft-riikonen-silc-flags-payloads-00.nroff

   1 .pl 10.0i
   2 .po 0
   3 .ll 7.2i
   4 .lt 7.2i
   5 .nr LL 7.2i
   6 .nr LT 7.2i
   7 .ds LF Riikonen
   8 .ds RF FORMFEED[Page %]
   9 .ds CF
  10 .ds LH Internet Draft
  11 .ds RH XXX
  12 .ds CH
  13 .na
  14 .hy 0
  15 .in 0
  16 .nf
  17 Network Working Group                                        P. Riikonen
  18 Internet-Draft
  19 draft-riikonen-flags-payloads-00.txt                         XXX
  20 Expires: XXX
  21
  22 .in 3
  23
  24 .ce 3
  25 SILC Message Flag Payloads
  26 <draft-riikonen-flags-payloads-00.txt>
  27
  28 .ti 0
  29 Status of this Memo
  30
  31 This document is an Internet-Draft and is in full conformance with
  32 all provisions of Section 10 of RFC 2026.  Internet-Drafts are
  33 working documents of the Internet Engineering Task Force (IETF), its
  34 areas, and its working groups.  Note that other groups may also
  35 distribute working documents as Internet-Drafts.
  36
  37 Internet-Drafts are draft documents valid for a maximum of six months
  38 and may be updated, replaced, or obsoleted by other documents at any
  39 time.  It is inappropriate to use Internet-Drafts as reference
  40 material or to cite them other than as "work in progress."
  41
  42 The list of current Internet-Drafts can be accessed at
  43 http://www.ietf.org/ietf/1id-abstracts.txt
  44
  45 The list of Internet-Draft Shadow Directories can be accessed at
  46 http://www.ietf.org/shadow.html
  47
  48 The distribution of this memo is unlimited.
  49
  50
  51 .ti 0
  52 Abstract
  53
  54 This memo describes the data payloads associated with the SILC Message
  55 Flags, as defined in the SILC Packet Protocol Internet Draft [SILC2].  The
  56 purpose of the Message Flags is to augment the function of the Private
  57 Message Payload and Channel Message Payload by allowing the sender to
  58 tell the receiver what type of data the payload includes, and how the
  59 data should be processed.  Some of the Message Flags may define additional
  60 payloads to be associated with the flag, and this memo describes these
  61 payloads.
  62
  63
  64
  65
  66
  67
  68
  69
  70 .ti 0
  71 Table of Contents
  72
  73 .nf
  74 1 Introduction ..................................................  x
  75   1.1 Requirements Terminology ..................................  x
  76 2 SILC Message Flags ............................................  x
  77 3 SILC Message Flag Payloads ....................................  x
  78   3.1 SILC_MESSAGE_FLAG_REQUEST .................................  x
  79   3.2 SILC_MESSAGE_FLAG_REPLY ...................................  x
  80   3.3 SILC_MESSAGE_FLAG_SIGNED ..................................  x
  81   3.4 SILC_MESSAGE_FLAG_DATA ....................................  x
  82 4 Security Considerations .......................................  x
  83 5 References ....................................................  x
  84 6 Author's Address ..............................................  x
  85
  86
  87 .ti 0
  88 1. Introduction
  89
  90 The Secure Internet Live Conferencing [SILC1] supports sending binary
  91 messages between users in the network.  To make the data sending, and
  92 processing at the receiver's end as simple as possible the SILC defines
  93 Message Flags to the Private Message Payload and Channel Message Payload
  94 [SILC2], which can help the receiver to decide how the data is encoded,
  95 and how it should be interpreted.  Some of the Message Flags may define
  96 additional payloads to be associated with the flag, but the [SILC2] does
  97 not define them.  This memo defines the payloads for those Message Flags
  98 that was marked to include additional payloads in [SILC2].
  99
 100 By defining the payloads for the Message Flags the SILC message payloads
 101 can be augmented to support any kind of data, which can be easily
 102 interpreted at the receiver end.  For example, it would be possible to
 103 send audio stream, video stream, image files and HTML pages as messages,
 104 and the receiver can either choose to ignore the message or to process
 105 it, or to perhaps pass the message to some application for processing.
 106 Without specific payloads for Message Flags it is almost impossible for
 107 the receiver to interpret binary data from the payload.
 108
 109
 110 .ti 0
 111 1.1 Requirements Terminology
 112
 113 The keywords MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED,
 114 MAY, and OPTIONAL, when they appear in this document, are to be
 115 interpreted as described in [RFC2119].
 116
 117
 118 .ti 0
 119 2 SILC Message Flags
 120
 121 The Message Flags was added to the SILC protocol for the reason that SILC
 122 provides sending binary data as messages between users, and entities in
 123 the network, and interpreting pure binary data is almost impossible.
 124 With the flags the purpose, the reason, and the way the message is
 125 supposed to be interpreted can be told to the recipient.  Other
 126 conferencing protocols which are usually ASCII based protocols do not have
 127 such problems since they do not generally support sending of binary data
 128 at all, or require encoding of the data before it can be sent over the
 129 network.
 130
 131 SILC Private Message Payload and Channel Message Payload can have flags
 132 that can augment the function of the payload.  The flags can tell for
 133 example that the message is a request, or a reply to an earlier received
 134 request.  They can tell that the message is some action that the sender
 135 is performing, or they can tell that the message is an auto reply, or
 136 that it is explicitly digitally signed by the sender.
 137
 138 The problem of Message Flags is that the space for flags mask is only 16
 139 bits, so there is a limited number of flags available.  For this reason a
 140 flag that defines some generic way of sending any kind of data as a
 141 message, and that it can be easily interpreted at the receiver's end is
 142 important.  For this reason the flag SILC_MESSAGE_FLAG_DATA was added to
 143 the protocol which can represent any data.  This memo desribes how this
 144 flag is used and how the associated payload is constructed and processed.
 145 This memo also describes payloads for all the other flags that can have
 146 associated payloads.
 147
 148
 149 .ti 0
 150 3 SILC Message Flag Payloads
 151
 152 The [SILC2] defines the flags which may have associated payloads.  This
 153 section will list these flags and define the payloads.
 154
 155
 156 .ti 0
 157 3.1 SILC_MESSAGE_FLAG_REQUEST
 158
 159 Currently this flag can be used in the context of application specific,
 160 service specific or vendor specific requests, and the data payload type is
 161 dependent of this context.  Therefore, payload is not defined for this
 162 flag in this memo.  This flag may also be masked with some other flag in
 163 the message payload, including with some other flag that defines
 164 additional payload.
 165
 166
 167 .ti 0
 168 3.2 SILC_MESSAGE_FLAG_REPLY
 169
 170 Currently this flag can be used in the context of application specific,
 171 service specific or vendor specific replies, and the data payload type is
 172 dependent of this context.  Therefore, payload is not defined for this
 173 flag in this memo.  This flag may also be masked with some other flag in
 174 the message payload, including with some other flag that defines
 175 additional payload.
 176
 177
 178 .ti 0
 179 3.3 SILC_MESSAGE_FLAG_SIGNED
 180
 181 Not defined yet.
 182
 183
 184 .ti 0
 185 3.4 SILC_MESSAGE_FLAG_DATA
 186
 187 This flag is used to represent any data as a message in the way that it
 188 can be easily interpreted by the recipient.  This flag is used to send
 189 MIME objects as messages from the sender to the receiver.  The MIME as
 190 defined in [RFC2045], [RFC2046], [RFC2047], [RFC2048] and [RFC2049] is
 191 well established protocol for sending different kind of data with many
 192 applications and protocols.  It support dozens of different media types
 193 and encodings, and for this reason is ideal for sending data in SILC
 194 message payloads as well.
 195
 196 When the receiver has checked that the message payload includes the
 197 SILC_MESSAGE_FLAG_DATA flag, it may then start parsing the MIME header.
 198 It would also be possible to pass the message to some application which
 199 can already interpret MIME objects.  If the receiver does not support the
 200 media type received in the MIME header, it SHOULD be treated as
 201 "application/octet-stream".  The receiver MAY also ignore and discard
 202 messages that it does not support.
 203
 204 The MIME header MUST be at the start of the data area of the Private
 205 Message Payload or Channel Message Payload.  The MIME header received in
 206 the data area of the payload SHOULD have the MIME-Version field at first
 207 and then Content-Type field.  The MIME-Version field is not required to be
 208 present in each body part of multipart entity.  Additionally the header
 209 MAY also include any other MIME compliant headers.  The character encoding
 210 for the MIME Header strings inside the message payload is US-ASCII, as
 211 defined in [RFC2045].  The actual MIME object may define additional
 212 character sets or encodings for the data it delivers.
 213
 214 Hence, the MIME Header in the message payload may be as follows:
 215
 216 .in 8
 217 .nf
 218 MIME-Version: 1.0
 219 Content-Type: discrete/composite
 220 Content-Transfer-Encoding: binary
 221 .in 3
 222
 223 The Content-Transfer-Encoding field behaves as defined in [RFC2045] and
 224 defines the encoding of the data in the MIME object.  The preferred data
 225 encoding with SILC is "binary".  However, many MIME media types defines
 226 their preferred encoding and they may be used if binary encoding is not
 227 suitable.
 228
 229 When sending large amounts of traffic or large files as MIME objects the
 230 limits of the SILC Packet needs to be taken into consideration.  The
 231 maximum length of SILC Packet is 2^16 bytes, and larger messages would
 232 need to be fragmented.  MIME provides way of fragmenting and reassembling
 233 messages, and it is to be done with SILC as defined in [RFC2046].  The
 234 MIME fragmentation is defined for gateway usage, but in case of SILC the
 235 sender may also start sending fragmented MIME objects.
 236
 237 This flag SHOULD NOT be masked with some other Message Flag that defines
 238 payloads.  Generally this sort of setting would be impossible for the
 239 receiver to interpret.  However, flags that does not define any specific
 240 payloads MAY be masked with this flag as well.  For example, this flag
 241 could be masked also with SILC_MESSAGE_FLAG_REQUEST flag.
 242
 243
 244 .ti 0
 245 4 Security Considerations
 246
 247 In case of SILC_MESSAGE_FLAG_DATA the implementors should pay special
 248 attention to the security implications of any media type that can cause
 249 the remote execution of any actions in the receiver's environment.  The
 250 [RFC2046] and [RFC2048] discusses more MIME specific security
 251 considerations.  Even though SILC provides secured messages, in case of
 252 MIME which can be used to transfer files and documents which are stored in
 253 the receiver's local environment, securing separately the MIME object may
 254 be desired.  For example, augmenting the MIME support in SILC messages to
 255 support S/MIME may be desired in some implementations.
 256
 257
 258
 259 .ti 0
 260 5 References
 261
 262 [SILC1]      Riikonen, P., "Secure Internet Live Conferencing (SILC),
 263              Protocol Specification", Internet Draft, April 2001.
 264
 265 [SILC2]      Riikonen, P., "SILC Packet Protocol", Internet Draft,
 266              April 2001.
 267
 268 [RFC2045]    Freed, N., et al., "Multipurpose Internet Mail Extensions
 269              (MIME) Part One: Format of Internet Message Bodies",
 270              Standards Track, RFC 2045, November 1996.
 271
 272 [RFC2046]    Freed, N., et al., "Multipurpose Internet Mail Extensions
 273              (MIME) Part Two: Media Types", Standards Track, RFC 2045,
 274              November 1996.
 275
 276 [RFC2047]    Moore K., "MIME (Multipurpose Internet Mail Extensions)
 277              Part Three: Message Header Extensions for Non-ASCII Text"
 278              Standards Track, RFC 2047, November 1996.
 279
 280 [RFC2048]    Freed, N., et al., "Multipurpose Internet Mail Extensions
 281              (MIME) Part Four: Registration Procedures", Standards
 282              Track, RFC 2048, November 1996.
 283
 284 [RFC2049]    Freed, N., et al., "Multipurpose Internet Mail Extensions
 285              (MIME) Part Five: Conformance Criteria and Examples",
 286              Standards Track, RFC 2049, November 1996.
 287
 288 [RFC2119]    Bradner, S., "Key Words for use in RFCs to Indicate
 289              Requirement Levels", BCP 14, RFC 2119, March 1997.
 290
 291
 292
 293 .ti 0
 294 6 Author's Address
 295
 296 Pekka Riikonen
 297 Snellmanninkatu 34 A 15
 298 70100 Kuopio
 299 Finland
 300
 301 EMail: priikone@iki.fi
 302
 303 This Internet-Draft expires XXX