idnits 2.17.1 draft-ietf-appsawg-media-type-suffix-regs-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 26, 2012) is 4376 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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) == Outdated reference: A later version (-14) exists of draft-ietf-appsawg-media-type-regs-05 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 5 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 Intended status: Standards Track April 26, 2012 5 Expires: October 26, 2012 7 Additional Media Type Structured Syntax Suffixes 8 draft-ietf-appsawg-media-type-suffix-regs-00 10 Abstract 12 This document defines several Structured Syntax Suffixes for use with 13 media type registrations. In particular, it defines and registers 14 the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" 15 Structured Syntax Suffixes, and updates the "+xml" Structured Syntax 16 Suffix registration. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 26, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. When to Use these Structured Syntax Suffixes . . . . . . . . . 2 53 3. The +json Structured Syntax Suffix . . . . . . . . . . . . . . 2 54 4. The +ber and +der Structured Syntax Suffixes . . . . . . . . . 3 55 5. The +fastinfoset Structured Syntax Suffix . . . . . . . . . . 4 56 6. The +wbxml Structured Syntax Suffix . . . . . . . . . . . . . 5 57 7. The +zip Structured Syntax Suffix . . . . . . . . . . . . . . 6 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 62 10.2. Informative References . . . . . . . . . . . . . . . . . 8 63 Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 8 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 [RFC3023] created the +xml suffix convention that may be used by 69 media types whose representation uses XML underneath, that is, they 70 could have been successfully parsed as if the media type had been 71 application/xml in addition to their being parsed as their media type 72 that is using the +xml suffix. [I-D.ietf-appsawg-media-type-regs] 73 defines a registry to be used for future Structured Syntax Suffixes. 75 A variety of Structured Syntax Suffixes have already been used in 76 some Media Type registration, in particular "+json", "+der", 77 "+fastinfoset" and "+wbxml". This document defines and registers 78 these Structured Syntax Suffixes in the Structured Syntax Suffix 79 registry, along with "+ber" and "+zip". In addition, this document 80 updates the "+xml" Structured Syntax Suffix registration. 82 Discussion of this document should occur in the Apps Area Working 83 Group (apps-discuss@ietf.org). [RFC Editor note: remove this 84 paragraph.] 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. When to Use these Structured Syntax Suffixes 92 Each of the Structured Syntax Suffixes defined in this document are 93 appropriate for use when the media type identifies the semantics of 94 the protocol payload. That is, knowing the semantics of the specific 95 media type provides for more specific processing of the content than 96 that afforded by generic processing of the underlying representation. 98 At the same time, using the suffix provides receivers of the media 99 types to do generic processing of the underlying representation in 100 cases where 1) they do not need to handle specially the particular 101 semantics of the exact media type, and, 2) there is no special 102 knowledge needed by such a generic processor in order to parse that 103 underlying representation other than what would be needed to parse 104 any example of that underlying representation. 106 3. The +json Structured Syntax Suffix 108 [RFC4627] defines the "application/json" media type. The suffix 109 "+json" may be used with any media type whose representation follows 110 that established for "application/json". The Message Type Structured 111 Syntax Suffix registration form follows: 113 Name JavaScript Object Notation (JSON) 115 +suffix +json 117 References [RFC4627] 119 Encoding considerations Per [RFC4627], JSON may be represented using 120 UTF-8, UTF-16, or UTF-32. When JSON is written 121 in UTF-8, JSON is 8bit compatible. When JSON is 122 written in UTF-16 or UTF-32, JSON is binary. 124 Fragment identifier considerations Media types using "+json" SHOULD 125 process any fragment identifiers defined for 126 "application/json" in the same way as defined for 127 that media type. (At publication of this 128 document, there is no fragment identification 129 syntax defined for "application/json".) Specific 130 media types using "+json" MAY identify additional 131 fragment identifier considerations, MAY define 132 processing for fragment identifiers that are 133 classed as errors for "application/json" and MAY 134 designate fragment identifiers defined for 135 "application/json" that SHOULD NOT be used. 137 Interoperability considerations n/a 139 Security considerations See [RFC4627] 141 Contact Apps Area Working Group (apps-discuss@ietf.org) 143 Author/Change controller The Apps Area Working Group has change 144 control over this registration. 146 4. The +ber and +der Structured Syntax Suffixes 148 The ITU defined the Basic Encoding Rules (BER) and Distinguished 149 Encoding Rules (DER) message transfer syntaxes in [ITU.X690.2008]. 150 The suffix "+ber" may be used with any media type whose 151 representation follows the BER message transfer syntax. The suffix 152 "+der" may be used with any media type whose representation follows 153 the DER message transfer syntax. The Message Type Structured Syntax 154 Suffix registration forms follows: 156 Name Basic Encoding Rules (BER) message transfer 157 syntax 159 +suffix +ber 160 References [ITU.X690.2008] 162 Encoding considerations BER is a binary encoding. 164 Fragment identifier considerations n/a 166 Interoperability considerations n/a 168 Security considerations There are no security considerations inherent 169 in BER. Each individual media type registered 170 with a +ber suffix may have additional security 171 considerations. 173 Contact Apps Area Working Group (apps-discuss@ietf.org) 175 Author/Change controller The Apps Area Working Group has change 176 control over this registration. 178 Name Distinguished Encoding Rules (DER) message 179 transfer syntax 181 +suffix +der 183 References [ITU.X690.2008] 185 Encoding considerations DER is a binary encoding. 187 Fragment identifier considerations n/a 189 Interoperability considerations n/a 191 Security considerations There are no security considerations inherent 192 in DER. Each individual media type registered 193 with a +der suffix may have additional security 194 considerations. 196 Contact Apps Area Working Group (apps-discuss@ietf.org) 198 Author/Change controller The Apps Area Working Group has change 199 control over this registration. 201 5. The +fastinfoset Structured Syntax Suffix 203 The ITU defined the Fast Infoset document format as a binary 204 representation of the XML Information Set in [ITU.X891.2005]. These 205 documents further define the "application/fastinfoset" media type. 206 The suffix "+fastinfoset" may be used with any media type whose 207 representation follows that established for "application/ 208 fastinfoset". The Message Type Structured Syntax Suffix registration 209 form follows: 211 Name Fast Infoset document format 213 +suffix +fastinfoset 215 References [ITU.X891.2005] 217 Encoding considerations Fast Infoset is a binary encoding. The 218 binary, quoted-printable and base64 content- 219 transfer-encodings are suitable for use with Fast 220 Infoset. 222 Fragment identifier considerations Media types using "+fastinfoset" 223 SHOULD process any fragment identifiers defined 224 for "application/fastinfoset" in the same way as 225 defined for that media type. (At publication of 226 this document, there is no fragment 227 identification syntax defined for "application/ 228 fastinfoset".) Specific media types using 229 "+fastinfoset" MAY identify additional fragment 230 identifier considerations, MAY define processing 231 for fragment identifiers that are classed as 232 errors for "application/fastinfoset" and MAY 233 designate fragment identifiers defined for 234 "application/fastinfoset" that SHOULD NOT be 235 used. 237 Interoperability considerations n/a 239 Security considerations There are no security considerations inherent 240 in Fast Infoset. Each individual media type 241 registered with a +fastinfoset suffix may have 242 additional security considerations. 244 Contact Apps Area Working Group (apps-discuss@ietf.org) 246 Author/Change controller The Apps Area Working Group has change 247 control over this registration. 249 6. The +wbxml Structured Syntax Suffix 251 The WAP Forum has defined the WAP Binary XML (WBXML) document format 252 as a binary representation of XML in [WBXML]. This document further 253 defines the "application/vnd.wap.wbxml" media type. The suffix 254 "+wbxml" may be used with any media type whose representation follows 255 that established for "application/vnd.wap.wbxml". The Message Type 256 Structured Syntax Suffix registration form follows: 258 Name WAP Binary XML (WBXML) document format 260 +suffix +wbxml 262 References [WBXML] 264 Encoding considerations WBXML is a binary encoding. 266 Fragment identifier considerations Media types using "+wbxml" SHOULD 267 process any fragment identifiers defined for 268 "application/vnd.wap.wbxml" in the same way as 269 defined for that media type. (At publication of 270 this document, there is no fragment 271 identification syntax defined for "application/ 272 vnd.wap.wbxml".) Specific media types using 273 "+wbxml" MAY identify additional fragment 274 identifier considerations, MAY define processing 275 for fragment identifiers that are classed as 276 errors for "application/vnd.wap.wbxml" and MAY 277 designate fragment identifiers defined for 278 "application/vnd.wap.wbxml" that SHOULD NOT be 279 used. 281 Interoperability considerations n/a 283 Security considerations There are no security considerations inherent 284 in WBXML. Each individual media type registered 285 with a +wbxml suffix may have additional security 286 considerations. 288 Contact Apps Area Working Group (apps-discuss@ietf.org) 290 Author/Change controller The Apps Area Working Group has change 291 control over this registration. 293 7. The +zip Structured Syntax Suffix 295 The ZIP format is a public domain, cross-platform, interoperable file 296 storage and transfer format, originally defined by PKWARE, Inc.; it 297 supports compression and encryption and is used as the underlying 298 representation by a variety of file formats. The media type 299 "application/zip" has been registered for such files. The suffix 300 "+zip" may be used with any media type whose representation follows 301 that established for "application/zip". The Message Type Structured 302 Syntax Suffix registration form follows: 304 Name ZIP file storage and transfer format 306 +suffix +zip 308 References [ZIP] 309 Encoding considerations ZIP is a binary encoding. 311 Fragment identifier considerations Media types using "+zip" SHOULD 312 process any fragment identifiers defined for 313 "application/zip" in the same way as defined for 314 that media type. (At publication of this 315 document, there is no fragment identification 316 syntax defined for "application/zip".) Specific 317 media types using "+zip" MAY identify additional 318 fragment identifier considerations, MAY define 319 processing for fragment identifiers that are 320 classed as errors for "application/zip" and MAY 321 designate fragment identifiers defined for 322 "application/zip" that SHOULD NOT be used. 324 Interoperability considerations n/a 326 Security considerations ZIP files support two forms of encryption: 327 Strong Encryption and AES 128-bit, 192-bit and 328 256-bit encryption; see the specification for 329 further details. Each individual media type 330 registered with a +zip suffix may have additional 331 security considerations. 333 Contact Apps Area Working Group (apps-discuss@ietf.org) 335 Author/Change controller The Apps Area Working Group has change 336 control over this registration. 338 8. IANA Considerations 340 See the Message Type Structured Syntax Suffix registration forms in 341 Section 3 - Section 7. 343 The existing Structured Syntax Suffix registration for "+xml" should 344 be modified to include the following 346 Fragment identifier considerations Media types using "+xml" SHOULD 347 process any fragment identifiers defined for 348 "application/xml" in the same way as defined for 349 that media type. (At publication of this 350 document, the fragment identification syntax 351 considerations for "application/xml" are defined 352 in [RFC3023].) Specific media types using "+xml" 353 MAY identify additional fragment identifier 354 considerations, MAY define processing for 355 fragment identifiers that are classed as errors 356 for "application/xml" and MAY designate fragment 357 identifiers defined for "application/xml" that 358 SHOULD NOT be used. 360 9. Security Considerations 361 See the Security considerations sections found in the Message Type 362 Structured Syntax Suffix registration forms from Section 3 - Section 363 6. 365 10. References 367 10.1. Normative References 369 [RFC4627] Crockford, D., "The application/json Media Type for 370 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 372 [ITU.X690.2008] 373 International Telecommunications Union, "Recommendation 374 ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules: 375 Specification of basic encoding Rules (BER), Canonical 376 encoding rules (CER) and Distinguished encoding rules 377 (DER)", ITU-T Recommendation X.690, November 2008. 379 [ITU.X891.2005] 380 International Telecommunications Union, "Recommendation 381 ITU-T X.891 | ISO/IEC 24824-1 (2007), Generic applications 382 of ASN.1: Fast infoset", ITU-T Recommendation X.891, May 383 2005. 385 [WBXML] Open Mobile Alliance, "Binary XML Content Format 386 Specification", OMA Wireless Access Protocol 387 WAP-192-WBXML-20010725-a, July 2001. 389 [ZIP] PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format 390 Specification", PKWARE .ZIP File Format Specification - 391 Version 6.3.2, September 2007. 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media 397 Types", RFC 3023, January 2001. 399 10.2. Informative References 401 [I-D.ietf-appsawg-media-type-regs] 402 Freed, N., Klensin, J. and T. Hansen, "Media Type 403 Specifications and Registration Procedures", Internet- 404 Draft draft-ietf-appsawg-media-type-regs-05, April 2012. 406 Appendix A. Change History 408 This section is to be removed before publication. 410 draft-ietf-appsawg-media-type-suffix-regs-00 Added the fragment 411 identifier consideration sections. 412 Added a note about +xml fragment identifier 413 considerations. 415 draft-hansen-media-type-suffix-regs-02 Added +zip. 416 Fixed up the ISO document references. 417 Minor changes. 419 draft-hansen-media-type-suffix-regs-01 Added +ber. 420 Minor changes. 422 Author's Address 424 Tony Hansen 425 AT&T Laboratories 426 200 Laurel Ave. South 427 Middletown, NJ 07748 428 USA 430 Email: tony+sss@maillennium.att.com