idnits 2.17.1 draft-ietf-appsawg-media-type-suffix-regs-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3023, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3023, updated by this document, for RFC5378 checks: 1999-09-24) -- 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.) -- The document date (October 22, 2012) is 4197 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-appsawg-media-type-regs' is defined on line 606, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.2008' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X891.2005' -- Possible downref: Non-RFC (?) normative reference: ref. 'WBXML' -- Possible downref: Non-RFC (?) normative reference: ref. 'ZIP' ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hansen 3 Internet-Draft AT&T Laboratories 4 Updates: 3023 (if approved) A. Melnikov 5 Intended status: Best Current Practice Isode Ltd 6 Expires: April 23, 2013 October 22, 2012 8 Additional Media Type Structured Syntax Suffixes 9 draft-ietf-appsawg-media-type-suffix-regs-07 11 Abstract 13 A content media type name sometimes includes partitioned meta- 14 information distinguish by a Structured Syntax, to permit noting an 15 attribute of the media as a suffix to the name. This document 16 defines several Structured Syntax Suffixes for use with media type 17 registrations. In particular, it defines and registers the "+json", 18 "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax 19 Suffixes, and provides a Message Type Structured Syntax Suffix 20 registration form for the "+xml" Structured Syntax Suffix. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 23, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. When to Use these Structured Syntax Suffixes . . . . . . . . . 2 58 3. Initial Structured Syntax Suffix Definitions . . . . . . . . . 3 59 3.1. The +json Structured Syntax Suffix . . . . . . . . . . . . 3 60 3.2. The +ber Structured Syntax Suffixes . . . . . . . . . . . 4 61 3.3. The +der Structured Syntax Suffixes . . . . . . . . . . . 5 62 3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 7 63 3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 8 64 3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 9 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 [RFC3023] created the +xml suffix convention that can be used when 76 defining names for media types whose representation uses XML 77 underneath. That is, they could have been successfully parsed as if 78 the media type had been application/xml in addition to their being 79 parsed as their media type that is using the +xml suffix. [I-D.ietf- 80 appsawg-media-type-regs] defines the Message Type Structured Syntax 81 Suffixes registry to be used for such Structured Syntax Suffixes. 83 A variety of Structured Syntax Suffixes have already been used in 84 some media type registrations, in particular "+json", "+der", 85 "+fastinfoset" and "+wbxml". This document defines and registers 86 these Structured Syntax Suffixes in the Structured Syntax Suffix 87 registry, along with "+ber" and "+zip". In addition, this document 88 updates [RFC3023] to formally register the "+xml" Structured Syntax 89 Suffix according to procedure defined in [I-D.ietf-appsawg-media- 90 type-regs]. 92 Discussion of this document should occur in the Apps Area Working 93 Group (apps-discuss@ietf.org). [RFC Editor note: remove this 94 paragraph.] 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2. When to Use these Structured Syntax Suffixes 101 Each of the Structured Syntax Suffixes defined in this document is 102 appropriate for use when the media type identifies the semantics of 103 the protocol payload. That is, knowing the semantics of the specific 104 media type provides for more specific processing of the content than 105 that afforded by generic processing of the underlying representation. 107 At the same time, using the suffix allows receivers of the media 108 types to do generic processing of the underlying representation in 109 cases where 111 they do not need to perform special handling of the particular 112 semantics of the exact media type, and, 114 there is no special knowledge needed by such a generic processor 115 in order to parse that underlying representation other than what 116 would be needed to parse any example of that underlying 117 representation. 119 3. Initial Structured Syntax Suffix Definitions 121 3.1. The +json Structured Syntax Suffix 123 [RFC4627] defines the "application/json" media type. The suffix 124 "+json" MAY be used with any media type whose representation follows 125 that established for "application/json". The Message Type Structured 126 Syntax Suffix registration form follows. See [I-D.ietf-appsawg- 127 media-type-regs] for definitions of each of the registration form 128 headings. 130 Name: JavaScript Object Notation (JSON) 132 +suffix: +json 134 References: [RFC4627] 136 Encoding considerations: Per [RFC4627], JSON is allowed to be 137 represented using UTF-8, UTF-16, or UTF-32. When 138 JSON is written in UTF-8, JSON is 8bit compatible 139 ([RFC2045]). When JSON is written in UTF-16 or 140 UTF-32, JSON is binary ([RFC2045]). 142 Fragment identifier considerations: 144 The syntax and semantics of fragment 145 identifiers specified for +json SHOULD be as 146 specified for "application/json". (At 147 publication of this document, there is no 148 fragment identification syntax defined for 149 "application/json".) 151 The syntax and semantics for fragment 152 identifiers for a specific "xxx/yyy+json" 153 SHOULD be processed as follows: 155 For cases defined in +json, where the 156 fragment identifier resolves per the +json 157 rules, then as specified in +json. 159 For cases defined in +json, where the 160 fragment identifier does not resolve per 161 the +json rules, then as specified in "xxx/ 162 yyy+json". 164 For cases not defined in +json, then as 165 specified in "xxx/yyy+json". 167 Interoperability considerations: n/a 169 Security considerations: See [RFC4627] 171 Contact: Apps Area Working Group (apps-discuss@ietf.org) 173 Author/Change controller: The Apps Area Working Group has change 174 control over this registration. 176 3.2. The +ber Structured Syntax Suffixes 178 The ITU defined the Basic Encoding Rules (BER) message transfer 179 syntax in [ITU.X690.2008]. The suffix "+ber" MAY be used with any 180 media type whose representation follows the BER message transfer 181 syntax. (The expert reviewer for Message Type Structured Syntax 182 Suffix registrations ought to be aware of the relationship between 183 BER and DER to aid in selecting the proper suffix.) The Message Type 184 Structured Syntax Suffix registration form for +ber follows: 186 Name: Basic Encoding Rules (BER) message transfer 187 syntax 189 +suffix: +ber 191 References: [ITU.X690.2008] 193 Encoding considerations: BER is a binary encoding. 195 Fragment identifier considerations: 197 At publication of this document, there is no 198 fragment identification syntax defined for 199 +ber. 201 The syntax and semantics for fragment 202 identifiers for a specific "xxx/yyy+ber" 203 SHOULD be processed as follows: 205 For cases defined in +ber, where the 206 fragment identifier resolves per the +ber 207 rules, then as specified in +ber. 209 For cases defined in +ber, where the 210 fragment identifier does not resolve per 211 the +ber rules, then as specified in "xxx/ 212 yyy+ber". 214 For cases not defined in +ber, then as 215 specified in "xxx/yyy+ber". 217 Interoperability considerations: n/a 219 Security considerations: Each individual media type registered with a 220 +ber suffix can have additional security 221 considerations. 223 BER has a type-length-value structure, and it is 224 easy to construct malicious content with invalid 225 length fields that can cause buffer overrun 226 conditions. 228 BER allows for arbitrary levels of nesting, which 229 may make it possible to construct malicious 230 content that will cause a stack overflow. 232 Interpreters of the BER structures should be 233 aware of these issues and should take appropriate 234 measures to guard against buffer overflows and 235 stack overruns in particular and malicious 236 content in general. 238 Contact: Apps Area Working Group (apps-discuss@ietf.org) 240 Author/Change controller: The Apps Area Working Group has change 241 control over this registration. 243 3.3. The +der Structured Syntax Suffixes 245 The ITU defined the Distinguished Encoding Rules (DER) message 246 transfer syntax in [ITU.X690.2008]. The suffix "+der" MAY be used 247 with any media type whose representation follows the DER message 248 transfer syntax. (The expert reviewer for Message Type Structured 249 Syntax Suffix registrations ought to be aware of the relationship 250 between BER and DER to aid in selecting the proper suffix.) The 251 Message Type Structured Syntax Suffix registration form for +der 252 follows: 254 Name: Distinguished Encoding Rules (DER) message 255 transfer syntax 257 +suffix: +der 259 References: [ITU.X690.2008] 261 Encoding considerations: DER is a binary encoding. 263 Fragment identifier considerations: 265 At publication of this document, there is no 266 fragment identification syntax defined for 267 +der. 269 The syntax and semantics for fragment 270 identifiers for a specific "xxx/yyy+der" 271 SHOULD be processed as follows: 273 For cases defined in +der, where the 274 fragment identifier resolves per the +der 275 rules, then as specified in +der. 277 For cases defined in +der, where the 278 fragment identifier does not resolve per 279 the +der rules, then as specified in "xxx/ 280 yyy+der". 282 For cases not defined in +der, then as 283 specified in "xxx/yyy+der". 285 Interoperability considerations: n/a 287 Security considerations: Each individual media type registered with a 288 +der suffix can have additional security 289 considerations. 291 DER has a type-length-value structure, and it is 292 easy to construct malicious content with invalid 293 length fields that can cause buffer overrun 294 conditions. 296 DER allows for arbitrary levels of nesting, which 297 may make it possible to construct malicious 298 content that will cause a stack overflow. 300 Interpreters of the DER structures should be 301 aware of these issues and should take appropriate 302 measures to guard against buffer overflows and 303 stack overruns in particular and malicious 304 content in general. 306 Contact: Apps Area Working Group (apps-discuss@ietf.org) 308 Author/Change controller: The Apps Area Working Group has change 309 control over this registration. 311 3.4. The +fastinfoset Structured Syntax Suffix 313 The ITU defined the Fast Infoset document format as a binary 314 representation of the XML Information Set in [ITU.X891.2005]. These 315 documents further define the "application/fastinfoset" media type. 316 The suffix "+fastinfoset" MAY be used with any media type whose 317 representation follows that established for "application/ 318 fastinfoset". The Message Type Structured Syntax Suffix registration 319 form follows: 321 Name: Fast Infoset document format 323 +suffix: +fastinfoset 325 References: [ITU.X891.2005] 327 Encoding considerations: Fast Infoset is a binary encoding. The 328 binary, quoted-printable and base64 content- 329 transfer-encodings are suitable for use with Fast 330 Infoset. 332 Fragment identifier considerations: 334 The syntax and semantics of fragment 335 identifiers specified for +fastinfoset SHOULD 336 be as specified for "application/fastinfoset". 337 (At publication of this document, there is no 338 fragment identification syntax defined for 339 "application/fastinfoset".) 341 The syntax and semantics for fragment 342 identifiers for a specific "xxx/ 343 yyy+fastinfoset" SHOULD be processed as 344 follows: 346 For cases defined in +fastinfoset, where 347 the fragment identifier resolves per the 348 +fastinfoset rules, then as specified in 349 +fastinfoset. 351 For cases defined in +fastinfoset, where 352 the fragment identifier does not resolve 353 per the +fastinfoset rules, then as 354 specified in "xxx/yyy+fastinfoset". 356 For cases not defined in +fastinfoset, then 357 as specified in "xxx/yyy+fastinfoset". 359 Interoperability considerations: n/a 360 Security considerations: There are no security considerations 361 inherent in Fast Infoset. Each individual media 362 type registered with a +fastinfoset suffix can 363 have additional security considerations. 365 Contact: Apps Area Working Group (apps-discuss@ietf.org) 367 Author/Change controller: The Apps Area Working Group has change 368 control over this registration. 370 3.5. The +wbxml Structured Syntax Suffix 372 The WAP Forum has defined the WAP Binary XML (WBXML) document format 373 as a binary representation of XML in [WBXML]. This document further 374 defines the "application/vnd.wap.wbxml" media type. The suffix 375 "+wbxml" MAY be used with any media type whose representation follows 376 that established for "application/vnd.wap.wbxml". The Message Type 377 Structured Syntax Suffix registration form follows: 379 Name: WAP Binary XML (WBXML) document format 381 +suffix: +wbxml 383 References: [WBXML] 385 Encoding considerations: WBXML is a binary encoding. 387 Fragment identifier considerations: 389 The syntax and semantics of fragment 390 identifiers specified for +wbxml SHOULD be as 391 specified for "application/vnd.wap.wbxml". 392 (At publication of this document, there is no 393 fragment identification syntax defined for 394 "application/vnd.wap.wbxml".) 396 The syntax and semantics for fragment 397 identifiers for a specific "xxx/yyy+wbxml" 398 SHOULD be processed as follows: 400 For cases defined in +wbxml, where the 401 fragment identifier resolves per the +wbxml 402 rules, then as specified in +wbxml. 404 For cases defined in +wbxml, where the 405 fragment identifier does not resolve per 406 the +wbxml rules, then as specified in "xxx 407 /yyy+wbxml". 409 For cases not defined in +wbxml, then as 410 specified in "xxx/yyy+wbxml". 412 Interoperability considerations: n/a 413 Security considerations: There are no security considerations 414 inherent in WBXML. Each individual media type 415 registered with a +wbxml suffix can have 416 additional security considerations. 418 Contact: Apps Area Working Group (apps-discuss@ietf.org) 420 Author/Change controller: The Apps Area Working Group has change 421 control over this registration. 423 3.6. The +zip Structured Syntax Suffix 425 The ZIP format is a public domain, cross-platform, interoperable file 426 storage and transfer format, originally defined by PKWARE, Inc.; it 427 supports compression and encryption and is used as the underlying 428 representation by a variety of file formats. The media type 429 "application/zip" has been registered for such files. The suffix 430 "+zip" MAY be used with any media type whose representation follows 431 that established for "application/zip". The Message Type Structured 432 Syntax Suffix registration form follows: 434 Name: ZIP file storage and transfer format 436 +suffix: +zip 438 References: [ZIP] 440 Encoding considerations: ZIP is a binary encoding. 442 Fragment identifier considerations: 444 The syntax and semantics of fragment 445 identifiers specified for +zip SHOULD be as 446 specified for "application/zip". (At 447 publication of this document, there is no 448 fragment identification syntax defined for 449 "application/zip".) 451 The syntax and semantics for fragment 452 identifiers for a specific "xxx/yyy+zip" 453 SHOULD be processed as follows: 455 For cases defined in +zip, where the 456 fragment identifier resolves per the +zip 457 rules, then as specified in +zip. 459 For cases defined in +zip, where the 460 fragment identifier does not resolve per 461 the +zip rules, then as specified in "xxx/ 462 yyy+zip". 464 For cases not defined in +zip, then as 465 specified in "xxx/yyy+zip". 467 Interoperability considerations: n/a 469 Security considerations: ZIP files support two forms of encryption: 470 Strong Encryption and AES 128-bit, 192-bit and 471 256-bit encryption; see the specification for 472 further details. Each individual media type 473 registered with a +zip suffix can have additional 474 security considerations. 476 Contact: Apps Area Working Group (apps-discuss@ietf.org) 478 Author/Change controller: The Apps Area Working Group has change 479 control over this registration. 481 4. IANA Considerations 483 See the Message Type Structured Syntax Suffix registration forms in 484 Section 3.1 - Section 3.6. 486 The following Structured Syntax Suffix registration for "+xml" shall 487 be used to reflect the information found in [RFC3023], with the 488 addition of fragment identifier considerations: 490 Name: Extensible Markup Language (XML) 492 +suffix: +xml 494 References: [RFC3023] 496 Encoding considerations: Per [RFC3023], XML is allowed to be 497 represented using both 7-bit and 8-bit encodings. 498 When XML is written in UTF-8, XML is 8bit 499 compatible ([RFC2045]). When XML is written in 500 UTF-16 or UTF-32, XML is binary ([RFC2045]). 502 Fragment identifier considerations: 504 The syntax and semantics of fragment 505 identifiers specified for +xml SHOULD be as 506 specified for "application/xml". (At 507 publication of this document, the fragment 508 identification syntax considerations for 509 "application/xml" are defined in [RFC3023], 510 sections 5 and 7.) 512 The syntax and semantics for fragment 513 identifiers for a specific "xxx/yyy+xml" 514 SHOULD be processed as follows: 516 For cases defined in +xml, where the 517 fragment identifier resolves per the +xml 518 rules, then as specified in +xml. 520 For cases defined in +xml, where the 521 fragment identifier does not resolve per 522 the +xml rules, then as specified in "xxx/ 523 yyy+xml". 525 For cases not defined in +xml, then as 526 specified in "xxx/yyy+xml". 528 Interoperability considerations: See [RFC3023]. 530 Security considerations: See [RFC3023] 532 Contact: Apps Area Working Group (apps-discuss@ietf.org) 534 Author/Change controller: The Apps Area Working Group has change 535 control over this registration. 537 5. Security Considerations 539 See the Security considerations sections found in the Message Type 540 Structured Syntax Suffix registration forms from Section 3.1 - 541 Section 3.5. 543 When updating a + registration, care should be taken to 544 review all previously-registered xxx/yyy+ media types as to 545 whether they might be affected by the updated + registration. 546 Because the generic fragment identifier processing rules take 547 precedence over media-type-specific rules, introducing new or 548 changing existing definitions may break the existing registrations of 549 specific media types, as well as particular implementations of 550 applications that process affected media types. Such changes can 551 introduce interoperability and security issues. 553 When updating the fragment identifier processing rules for a specific 554 xxx/yyy+ media type, care should be taken to review the 555 generic fragment identifier processing rules for the + 556 registration and not introduce any conflicts. Because the generic 557 fragment identifier processing rules take precedence over media-type- 558 specific rules, such conflicting processing requirements should be 559 ignored by an implementation, but such conflicts can introduce 560 interoperability and security issues. 562 Note that [FRAGID-BP] provides additional advice to designers of 563 fragment identifier rules for media type suffixes and specific media 564 types. 566 6. References 568 6.1. Normative References 570 [RFC4627] Crockford, D., "The application/json Media Type for 571 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 573 [ITU.X690.2008] 574 International Telecommunications Union, "Recommendation 575 ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules: 576 Specification of basic encoding Rules (BER), Canonical 577 encoding rules (CER) and Distinguished encoding rules 578 (DER)", ITU-T Recommendation X.690, November 2008. 580 [ITU.X891.2005] 581 International Telecommunications Union, "Recommendation 582 ITU-T X.891 | ISO/IEC 24824-1 (2007), Generic applications 583 of ASN.1: Fast infoset", ITU-T Recommendation X.891, May 584 2005. 586 [WBXML] Open Mobile Alliance, "Binary XML Content Format 587 Specification", OMA Wireless Access Protocol 588 WAP-192-WBXML-20010725-a, July 2001. 590 [ZIP] PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format 591 Specification", PKWARE .ZIP File Format Specification - 592 Version 6.3.2, September 2007. 594 [RFC2045] Freed, N. and N.S. Borenstein, "Multipurpose Internet Mail 595 Extensions (MIME) Part One: Format of Internet Message 596 Bodies", RFC 2045, November 1996. 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, March 1997. 601 [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media 602 Types", RFC 3023, January 2001. 604 6.2. Informative References 606 [I-D.ietf-appsawg-media-type-regs] 607 Freed, N., Klensin, J. and T. Hansen, "Media Type 608 Specifications and Registration Procedures", Internet- 609 Draft draft-ietf-appsawg-media-type-regs-14, June 2012. 611 [FRAGID-BP] 612 Tennison, J., "Best Practices for Fragment Identifiers and 613 Media Type Definitions", July 2012, . 616 Appendix A. Change History 618 This section is to be removed before publication. 620 draft-ietf-appsawg-media-type-suffix-regs-07 Added information based 621 on IANA and GEN-ART reviews. 623 draft-ietf-appsawg-media-type-suffix-regs-06 Clarified why this 624 document updates RFC 3023. 626 draft-ietf-appsawg-media-type-suffix-regs-05 Added an Informative 627 reference to http://www.w3.org/TR/fragid-best- 628 practices/. 629 Minor editorial changes. 631 draft-ietf-appsawg-media-type-suffix-regs-03 Added generic fragment 632 idenfier rules to +ber/+der to make them 633 consistant with other registrations. 634 Added some warning about 635 how adding/changing fragment identifier rules for 636 a +suffix can affect fragment identifier 637 processing rules for previously registered xxx/ 638 yyy+suffix media types. 640 draft-ietf-appsawg-media-type-suffix-regs-02 Added BER/DER security 641 considerations. 642 Reworked fragment 643 identifier wording some more. 645 draft-ietf-appsawg-media-type-suffix-regs-01 Reordered the sections. 646 Cleaned up some MUSTard. 647 Fixed some references. 648 Added encoding 649 considerations. 650 Reworked fragment 651 identifier wording. 653 draft-ietf-appsawg-media-type-suffix-regs-00 Added the fragment 654 identifier consideration sections. 655 Added a note about +xml 656 fragment identifier considerations. 658 draft-hansen-media-type-suffix-regs-02 Added +zip. 659 Fixed up the ISO document 660 references. 661 Minor changes. 663 draft-hansen-media-type-suffix-regs-01 Added +ber. 664 Minor changes. 666 Authors' Addresses 668 Tony Hansen 669 AT&T Laboratories 670 200 Laurel Ave. South 671 Middletown, NJ 07748 672 USA 674 Email: tony+sss@maillennium.att.com 675 Alexey Melnikov 676 Isode Ltd 677 5 Castle Business Village 678 36 Station Road 679 Hampton, Middlesex TW12 2BX 680 UK 682 Email: Alexey.Melnikov@isode.com