idnits 2.17.1 draft-finlayson-mafp-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 350 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 57 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 53 instances of lines with control characters in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 332, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-06) exists of draft-ietf-mmusic-sdp-04 -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ross Finlayson 2 Internet-Draft Live Networks 3 Expire in six months 1998.01.16 5 The Multicast Attribute Framing Protocol 7 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa) , nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast ), or 25 ftp.isi.edu (US West Coast). 27 2. Abstract 29 The Internet has recently seen the emergence of applications that involve 30 the ongoing transmission, or ''pushing'', of structured data from a server to 31 one or more client nodes. Most current applications send this data using 32 unicast communications - usually over TCP connections. However, similar 33 applications can also be implemented using multicast-based protocols. 34 Multicast not only improves the scalability of this particular class of 35 application, but also makes possible an additional class of application in 36 which the participants can act as peers - sending data as well as receiving. 38 This Internet Draft describes the ''Multicast Attribute Framing Protocol'' 39 (MAFP) - a generic, attribute-based data representation, intended for a 40 wide variety of multicast-based applications. It is currently being used 41 to implement the ''multikit'' generic multicast session browser 42 (http://www.lvn.com/multikit). This draft describes an early version of 43 MAFP that is likely to undergo changes in the future. However, it is 44 being described now, in the hope that it will promote open discussion of 45 this and similar protocols - ideally leading to the adoption of an open, 46 interoperable standard for this class of application. 48 3. Introduction 50 MAFP is used to describe one or more objects that are being transmitted or 51 'announced' over the Internet, typically to a multicast address. (Other 52 transmission mechanisms are possible, however, including unicast (UDP or 53 TCP), or even email.) These announced objects are called "programs" (by 54 analogy with TV programs, not computer programs). 56 Each program is announced to a specific "directory". That is, an 57 announcement in MAFP cspecifies both the program being announced, and a 58 directory to which it is being announced. More than one program can - and 59 typically will - be announced to the same directory (in separate 60 announcements). If the announcements are being made using multicast, then 61 the directory will be associated with a multicast address. 63 A program is described primarily as a set of "attributes" (name-value 64 pairs). MAFP does not define any semantics for these attributes; the names 65 and values can be treated merely as opaque strings. (Future documents may 66 define attribute profiles for specific applications.) 68 In addition to attributes, some program descriptions may also contain IP 69 address, port, and TTL ("time to live") parameters. Recipient(s) may use 70 these parameters for additional communication (usually in a manner defined 71 by the attributes). These parameters are distinguished from attributes; 72 this allows firewalls or proxies to perform appropriate checking and/or 73 translation, without having to understand anything about the attributes 74 themselves. 76 MAFP was inspired in part by SDP [2] - a format designed specifically for 77 announcing multimedia sessions (primarily, over the MBone). MAFP, however, 78 extends the SDP model in the following ways: 79 - directories are 'first-class' objects, and can be 'announced' 80 within other directories, just like any other session 81 - sessions can have arbitrary attributes (not just the fixed set of 82 attributes that were defined for SDP) 83 - SDP's session bundling mechanism is generalized: Any arbitrary 84 collection of sessions can be combined and announced as a single 85 'bundle' 87 MAFP describes the layout (within a packet) of a "program announcement". 88 MAFP is independent of the underlying transport protocol, which may have 89 only "best efforts" datagram semantics (e.g., UDP), or may provide some 90 degree of reliable delivery. The only requirement is that a program 91 announcement either be delivered entirely, or not at all. (Future versions 92 of MAFP, however, may also allow announcements to be fragmented in ways that 93 might be exploited by underlying transport protocols [3].) 95 Section 4 describes the syntax of a MAFP "program announcement". In 96 section 5 we present examples of MAFP announcements. We close with an 97 outline of possible future directions for this protocol. 99 4. The Syntax of a MAFP Packet 101 4.1 Basic Lexical Structure and Syntax 103 The lexical structure of the current version of MAFP is based upon that of 104 the Tcl scripting language [4]. Future versions of MAFP will be more 105 language-independent. 107 A MAFP program announcement is a character string, possibly terminated by a 108 NUL character (i.e., value zero) or a LF (ASCII 0x0a). It consists of a 109 "list" in the Tcl sense - i.e., a sequence of string "elements", each 110 separated by white-space. Tcl's quoting rules apply to elements - in 111 particular, elements that contain white space are enclosed in braces {}. 113 A MAFP program announcement is given by the following BNF grammar : 115 ::= \ 116 118 ::= \ 119 121 ::= \ 122 "general" 123 | "channel" 124 | "bundle" 126 ::= \ 127 128 | "|" 129 | "|" 131 ::= \ 132 133 | 135 ::= 136 ::= 138 ::= 139 ::= x.y.z.w (i.e., a 'dotted quad' IPv4 address) 140 ::= \ 141 a string representing a decimal integer in the range 0 through 65535 142 ::= 143 ::= \ 144 a string representing a decimal integer in the range 0 through 255 146 The terminal symbols "general", "channel", "bundle", and "|" appear exactly 147 as shown (without the quote symbols). 149 The remaining (nonobvious) nonterminal symbols - , , 150 , , , , , and - are described below 153 4.2. 155 This field indicates the version of MAFP that is being used. The current 156 version of MAFP is 3, represented by the character '3' (ASCII 0x33). To 157 allow for possible future versions of MAFP that may use a raw binary 158 encoding, this must be the first character in the packet, and must be 159 immediately followed by a space (ASCII 0x20). 161 4.3. 163 The describes the nature of the announcement, and thus the action 164 to be taken by each receiver. Three commands are currently defined: "d", 165 "p", and "x". 167 Both the "p" and "d" commands are handled as follows: 168 - If the receiver has no current record of the announced program, then 169 it should create such a record, unless it also has no current record 170 of the 'parent' program (see below). 171 - If the receiver has a current record of the announced program, then it 172 should update its existing record with the information from the 173 announcement. Any new attributes defined in the announcement 174 are added to the existing record, but any attributes in the existing 175 record that are not redefined in the announcement should remain. 176 When handling a "d" command, the receiver updates its local copy of the 177 announced program, but does *not* re-announce it to anyone else. The "p" 178 command, on the other hand, indicates that each recipient, in addition to 179 updating its local state, should also participate in announcing this 180 program to others. (The "d" command is analogous to someone holding up 181 ("displaying") a sign: the sign is visible only while the person is 182 present. The "p" command, on the other hand, is analogous to someone 183 "posting" a sign on a notice board: the sign remains visible even after the 184 person has left.) 186 The "x" command indicates that the program is to be *deleted* from the 187 specified directory. Like the "p" command, each receiver should also 188 participate in announcing this deletion to others. If the receiver does 189 not already have a record of this program, then he should add a 'dummy' 190 record in its place, indicating that the program has been deleted. This 191 allows the receiver to ignore any 'old' announcement for the same program 192 that it may see later. (See the description of below.) 194 4.4. 196 The field is a non-negative integer (string) that indicates 197 the 'version' of the announcement. A sender should increase the value of 198 this field if it changes the announcement in some way - e.g., when an 199 attribute changes, or when a "d" or "p" announcement is changed to an "x" 200 (i.e., deletion) announcement, or vice versa. Receivers must ignore any 201 announcement whose is less than that which it already has 202 on-record for the program. 204 MAFP does not define the contents of this field - only that this it is a 205 non-negative integer that is increased (i.e., added to) whenever a program's 206 announcement changes. If more than one node can make changes to a program, 207 then MAFP does not specify how these nodes coordinate their respective 208 fields, except for specifying that "the highest value wins". 209 One possible approach, however, is to simply use timestamps (under the 210 assumption that the nodes' clocks are at least roughly synchronized). 212 4.5. Program Ids 214 , , and are each "program ids": unique 215 identifiers that denote, respectively: 216 - the directory to which the announcement is being made, 217 - the program that is being announced, and 218 - the parent of the program that's being announced, 219 or "{}" (the empty string) if the program has no parent. 220 The "parent" mechanism is used to implement a simple attribute inheritance 221 hierarchy. Any attributes of the parent that are not redefined in an 222 announcement of the child are inherited by the child. 224 At present, MAFP does not define the structure of program ids; they can 225 merely be considered opaque strings. Specific applications that use MAFP 226 may impose some structure on program ids - e.g., to ensure global 227 uniqueness. Future versions of MAFP might also impose some structure - 228 e.g., to embed a public key representing the program's 'owner'. 230 The receiver should ignore an announcement if the does not 231 correspond to the transmission mechanism (e.g., a multicast group address) 232 on which the announcement is being made. 234 As a special case, a of "SELF" (without the quote symbols) 235 indicates that this description is for the directory itself, rather than 236 for a program within the directory. In this case, must be "d" 237 or "p" only - not "x", and the fields must denote 238 a "channel" (see below). 240 This (optional) self-description mechanism allows a receiver to learn the 241 complete attributes of a directory, given only the directory's IP 242 address and port. 244 4.6. 246 This field specifies the time at which the announced program will expire 247 (and can thus be removed from the receiver's records). It is an integer in 248 "Unix time format": the number of seconds since 1/1/1970 UTC. 250 Note that, because of attribute inheritance, a program's expiration date 251 should not exceed that of its parent. If an announcement is received that 252 attempts to set a program's expiration date to a later time than that of its 253 parent, then the parent's expiration date should be used instead. 255 4.7. 257 In the future this field will be used to specify an encryption key for a 258 "channel" (see below). Currently, the only value defined for this field is 259 the string "nokey", meaning: no encryption is performed. 261 4.8. Channels and Bundles 263 MAFP recognizes three distinct kinds of program: channels, bundles, and 264 'general' (everything else). 266 A channel has an associated IP address, port number, and TTL. (A directory 267 is itself a channel.) 269 Bundles are used to implement a simple grouping mechanism. An announcement 270 of a bundle includes each of its members. 272 5. Examples 274 The first example below illustrates the announcement of a program - 275 specifically a bundle "prog2" with two members: (i) a channel "prog4" (note 276 the multicast address, port, and TTL), and (ii) a 'general' program (i.e., 277 neither a channel nor a bundle) "prog6". (The announcement is being made 278 to the directory "prog1".) 280 Each of the three programs (the bundle and its two members) has an attribute 281 named "anAttributeName"; the channel has an additional attribute named 282 "anotherAttributeName". Note the use of braces to 'quote' multi-word 283 attribute values. 285 The line breaks in this example are for clarification only. Newline 286 characters must *not* appear in an actual "on-the-wire" announcement. 288 2 d 0 prog1 289 prog2 prog3 857203200 bundle 290 prog4 prog5 857203200 channel 291 238.236.141.215 50470 127 nokey 292 anAttributeName {This is an attribute of the channel} | 293 prog6 prog7 857203200 general 294 anAttributeName {This is an attribute of the 'general' program} 295 anotherAttributeName foobar | 296 anAttributeName {This is an attribute of the 'bundle'} 298 The second example - taken from an actual use of MAFP - illustrates the 299 announcement of an earthquake report. (Once again, the line breaks are for 300 clarification only.) 302 2 p 880038262 P:206.86.37.13:78801286 303 P:206.86.37.1:879941367:world R::TEMPLATE-AtomicNonChannel 304 880200567 general 305 info {SAMOA ISLANDS REGION} 306 startTime 879941367 307 magnitude 5.4Ms 308 longitude 175.79W 309 latitude 14.04S 310 depth 33.0 312 6. Possible Future Directions 314 (In no particular order) 316 - Make the syntax more programming language independent, and (ideally) 317 leverage off an existing attribute description format - possibly XML [5] 318 - Use NTP time format (instead of Unix)? 319 - Define attributes as (name, type, value) triples, rather than 320 (name, value) pairs? 321 - Define a way to delete (rather than just redefine) attributes 322 - Define a compression scheme, to efficiently support low-bandwidth links 323 - Allow program announcements to be digitally signed, for integrity 324 - Try to be as consistent as possible with SAP [6], and/or any 325 reliable multicast protocols that emerge from the IRTF's 326 "reliable multicast" working group [7]. 327 - I18N 328 - Support IPv6 addresses as well as IPv4 330 6. References 332 [1] "multikit" - a distributed, multicast-based directory browser 333 http://www.lvn.com/multikit/ 334 [2] M Handley, V. Jacobson. SDP: Session Description Protocol 335 draft-ietf-mmusic-sdp-04.txt 336 [3] David D. Clark, David L. Tennenhouse. Architectural Considerations for 337 New Generation Protocols. SIGCOMM 1990. 338 ("Application Layer Framing") 339 [4] Tcl/Tk 340 http://sunscript.sun.com/ 341 [5] World Wide Web Consortium. Extensible Markup Language 342 http://www.w3.org/TR/WD-xml 343 [6] M Handley. SAP: Session Announcement Protocol 344 draft-ietf-mmusic-sap-00.txt 345 [7] IRTF "reliable multicast" working group 346 http://www.east.isi.edu/RMRG/