- Ietf-types - example.com

Request for review of media type registration in draft-ietf-keyprov-dskpp-10.txt
by Polk, William T. 22 Apr '10

22 Apr '10

Folks, Please review the following media type registration from draft-ietf-keyprov-dskpp-10.txt, which is currently in IETF Last Call. Note: The text is reproduced exactly from the draft. Based on recent experiences, I understand that the following lines should be deleted: To: ietf-types(a)iana.org Subject: Registration of MIME media type application/dskpp+xml Thanks, Tim Polk ------------ 12.3. MIME Media Type Registration This section registers the "application/dskpp+xml" MIME type: To: ietf-types(a)iana.org Subject: Registration of MIME media type application/dskpp+xml MIME media type name: application MIME subtype name: dskpp+xml Required parameters: (none) Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See [RFC3203], Section 3.2. Security considerations: This content type is designed to carry protocol data related to key management. Security mechanisms are built into the protocol to ensure that various threats are dealt with. Interoperability considerations: This content type provides a basis for a protocol. Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.] Applications which use this media type: Protocol for key exchange. Additional information: Magic Number(s): (none) File extension(s): .xmls Macintosh File Type Code(s): (none) Person & email address to contact for further information: Andrea Doherty (andrea.doherty(a)rsa.com) Intended usage: LIMITED USE Author/Change controller: The IETF Other information: This media type is a specialization of application/xml [RFC3203], and many of the considerations described there also apply to application/dskpp+xml.

2 1

Request for review of media type from draft-ietf-keyprov-pskc-05.txt
by Polk, William T. 22 Apr '10

22 Apr '10

Folks, Please review the following media type registration excerpted from draft-ietf-keyprov-pskc-05.txt, which is currently in IETF Last Call. Thanks, Tim Polk ----------------------- 12.1. Content-type registration for 'application/pskc+xml' This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [RFC4288] and guidelines in RFC 3023 [RFC3023]. MIME media type name: application MIME subtype name: pskc+xml Mandatory parameters: none Optional parameters: charset Indicates the character encoding of enclosed XML. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC3023], Section 3.2. Security considerations: This content type is designed to carry PSKC protocol payloads. Interoperability considerations: None Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.] Applications which use this media type: This MIME type is being used as a symmetric key container format for transport and provisioning of symmetric keys (One Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of strong authentication devices. As such, it is used for key provisioning systems. Additional information: Magic Number: None File Extension: .pskcxml Macintosh file type code: 'TEXT' Personal and email address for further information: Philip Hoyer, Philip.Hoyer(a)actividentity.com Intended usage: LIMITED USE Author: This specification is a work item of the IETF KEYPROV working group, with mailing list address <keyprov(a)ietf.org>. Change controller: The IESG <iesg(a)ietf.org>

2 1

application/pkcs10
by Sean Turner 22 Apr '10

22 Apr '10

I'd like to request an expert review for the application/pkcs10 media type registration found in: http://tools.ietf.org/html/draft-turner-application-pkcs10-media-type The text for formation of the application/pkcs10 media type is adapted from RFC 2311. Only minor changes were made, as can be seen in the diffs between version -00 and -01. The changes in -02 were editorial. An IETF LC has been requested for this ID. spt

2 4

Re: plan for getting media type registrations updated w.r.t. media fragments?
by Dan Connolly 22 Apr '10

22 Apr '10

+cc ietf-types(a)alvestrand.no ; thread begins at http://lists.w3.org/Archives/Public/public-media-fragment/2010Apr/0039.html On Wed, 2010-04-21 at 09:32 +1000, Silvia Pfeiffer wrote: > On Wed, Apr 21, 2010 at 2:56 AM, Dan Connolly <connolly(a)w3.org> wrote: > > http://www.w3.org/TR/2010/WD-media-frags-20100413/#standardisation-terminol… [...] > > "The Media Fragment WG has no authority to update registries of all > > targeted media types. ... We recommend media type owners to harmonize > > their existing schemes with the ones proposed in this document and > > update or add the fragment semantics specification to their media type > > registration." > > > > Is there a plan to get that recommendation implemented? > > I can offer to do an update of the Ogg RFC > http://www.ietf.org/rfc/rfc5334.txt with these fragment > specifications. > > Though, to be honest, it will be easier to just get implementations > and then, if they catch on, update the RFC. Well, that's a plan of sorts... but it's important to coordinate that with the IETF. It's not polite for W3C to unilaterally encourage implementations to deploy certain designs that will constrain updates to IETF RFCs. I wonder who to coordinate with from the IETF side... The http://www.alvestrand.no/mailman/listinfo/ietf-types page says it's owned/run by Harald Alvestrand and Mark Baker (distobj). Does this play make sense to you? Otherwise, Mark N., would you suggest anybody in particular to coordinate with? > The reason that we can do implementations without much issues is that > virtually no other implementations of fragment schemes on media > resources exist. Even where schemes were developed such as at YouTube, > these schemes were not done on the media resource, but on the Web page > URLs. Also see http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#Existing… > for a more indepth analysis of the state of affairs. The exisiting > MPEG scheme has not been implemented anywhere FAIK and would not clash > since it always starts with mp(). > > Cheers, > Silvia. > -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E

1 0

Request for MIME media type Application/Standards Tree
by Adriano.Santoni 22 Apr '10

22 Apr '10

Name : Adriano Santoni Email : adriano.santoni(a)actalis.it <mailto:adriano.santoni@actalis.it> MIME media type name : application MIME subtype name : timestamped-data Required parameters : None Optional parameters : None Encoding considerations : binary This media type may require encoding on transports not capable of handling binary. Security considerations : See the Security considerations in the published specification. Interoperability considerations : None Published specification :RFC 5544 Applications which use this media : Any application supporting the TimeStampedData format. Additional information : 1. Magic number(s) : None 2. File extension(s) : .TSD 3. Macintosh file type code : None 4. Object Identifiers: None None Person to contact for further information : 1. Name : Adriano Santoni 2. Email : adriano.santoni(a)actalis.it <mailto:adriano.santoni@actalis.it> Intended usage : Common Carries a TimeStampedData envelope, wrapping a file (or a reference to it) with the corresponding temporal evidence. Author/Change controller : Adriano Santoni Actalis S.p.A. adriano.santoni(a)actalis.it <mailto:adriano.santoni@actalis.it>

3 5

Potential media type registration: application/metalink4+xml for Metalink Download Description Format
by Anthony Bryan 22 Apr '10

22 Apr '10

>From http://tools.ietf.org/html/draft-bryan-metalink application/metalink4+xml MIME type A Metalink Document, when serialized as XML 1.0, can be identified with the following media type: MIME media type name: application MIME subtype name: metalink4+xml Mandatory parameters: None. Optional parameters: "charset": This parameter has semantics identical to the charset parameter of the "application/xml" media type as specified in [RFC3023]. Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], Section 3.2. Security considerations: As defined in this specification. In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], Section 10. Interoperability considerations: There are no known interoperability issues. Published specification: This specification. Applications that use this media type: No known applications currently use this media type. Additional information: Magic number(s): As specified for "application/xml" in [RFC3023], Section 3.2. File extension: .meta4 Fragment identifiers: As specified for "application/xml" in [RFC3023], Section 5. Base URI: As specified in [RFC3023], Section 6. Macintosh File Type code: TEXT Person and email address to contact for further information: Anthony Bryan <anthonybryan(a)gmail.com> Intended usage: COMMON Author/Change controller: IESG thank you, -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads

2 2

application/pkcs8
by Sean Turner 21 Apr '10

21 Apr '10

I believe that the application/pkcs8 media type registration was reviewed by these experts previously; however, the last time it was reviewed it was in http://tools.ietf.org/html/draft-ietf-sip-certs. The registration was moved from the sip-certs ID to an ID that updates PKCS#8 (http://tools.ietf.org/html/draft-turner-asymmetrickeyformat-04) to keep all the PKCS#8 information in one place. Can someone confirm whether or not a new review is needed? If it is, can the clock start now? spt

3 6

Re: Request for review of media types in draft-ietf-pkix-tamp
by Alfred Hönes 21 Apr '10

21 Apr '10

Please make sure draft-ietf-pkix-tamp follows BCP 13, RFC 4288. (It is on the level of the obsoleted predecessor of that memo.) RFC 4288 explains at lenght why the use of "MIME" in the context of Media Types is a bad idea, since those are being used at large outside the original eMail context of MIME (the second "M" in "MIME"), in particular in HTTP (and SIP) context. So please delete all instances of the word "MIME" from Appendix B and use the updated registration template presented in RFC 4288 throughout the Appendix! In particular, use plain "media type" / "media subtype" in the prose and "type name" / "subtype name" in the registration clauses. Question: Are the file extensions actually to be given in upper case? Kind regards, Alfred Hönes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah(a)TR-Sys.de | +------------------------+--------------------------------------------+

2 1

Registration of media type application/its+xml
by Felix Sasaki 21 Apr '10

21 Apr '10

MIME media type name: application MIME subtype name: its+xml Required parameters: none Optional parameters: charset This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in IETF RFC 3023. Encoding considerations: Identical to those of "application/xml" as described in IETF RFC 3023, section 3.2, as applied to an ITS document. Security considerations: An ITS 1.0 document may cause arbitrary URIs or IRIs to be dereferenced, via the @xlink:href attribute at the its:rules element. Therefore, the security issues of [RFC3987] Section 8 should be considered. In addition, the contents of resources identified by file: URIs can in some cases be accessed, processed and returned as results. An implementation of ITS global rules requires the support of XPath 1.0 or its successor. Hence, processing of global rules might encompass dereferencing of URIs or IRIs during computation of XPath expressions. Arbitrary recursion is possible, as is arbitrarily large memory usage, and implementations may place limits on CPU and memory usage, as well as restricting access to system-defined functions. ITS 1.0 permits extensions. Hence it is possible that application/its+xml may describe content that has security implications beyond those described here. Interoperability considerations: There are no known interoperability issues. Published specifications: http://www.w3.org/TR/2007/REC-its-20070403/ Applications which use this media type: This new media type is being registered to allow for deployment of ITS 1.0 on the World Wide Web. Additional information: File extension: its Fragment identifiers: A syntax identical to that of "application/xml" as described in IETF RFC 3023. Base URI: As specified in IETF RFC 3023, section 6. Macintosh File Type code: TEXT Person and email address to contact for further information: World Wide Web Consortium <web-human(a)w3.org> Intended usage: COMMON Author/Change controller: The Internationalization Tag Set (ITS) 1.0 specification set is a work product of the World Wide Web Consortium's Internationalization Tag Set Working Group. The W3C has change control over this specification.

2 1

Request for review of media types in draft-ietf-pkix-tamp
by Polk, William T. 21 Apr '10

21 Apr '10

Folks, I originally requested this review on 12 April, but just now checked the archives and realized that the message did not appear on the list. I have now subscribed to the list, so hopefully we will get a better result this time! Given the number of media types, please let me know if the usual two week timeline presents a problem. Thanks, Tim Polk ------ Forwarded Message From: "Polk, William T." <william.polk(a)nist.gov> Date: Mon, 12 Apr 2010 11:35:53 -0400 To: <ietf-types(a)iana.org> Subject: Request for review of media types in draft-ietf-pkix-tamp Folks, The PKIX WG specification "Trust Anchor Management Protocol (TAMP)", which is available at http://www.ietf.org/id/draft-ietf-pkix-tamp-07.txt, is currently in IESG Evaluation. Unfortunately, this specification includes eleven MIME media types which were never announced on this list. I am now (belatedly) requesting that review. The following excerpt from the Internet-Draft contains the media type registrations for the eleven types present in this document. ---- excerpt from draft-ietf-pkix-tamp-07.txt ------- Internet-Draft TAMP March 2010 Appendix B. MIME Media Type Registrations Eleven MIME media type registrations are provided in this appendix. As noted in Section 2, in all cases TAMP messages are encapsulated within ContentInfo structures. Signed messages are additionally encapsulated within a SignedData structure. B.1. application/tamp-status-query To: ietf-types(a)iana.org Subject: Registration of MIME media type application/ tamp-status-query MIME media type name: application MIME subtype name: tamp-status-query Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: Carries a signed request for status information. Integrity protection is discussed in section 4.1. Replay detection is discussed in section 6. Interoperability considerations: None Published specification: TBD Applications that use this media type: TAMP clients responding to requests for status information. Additional information: Magic number(s): None File extension(s): .TSQ Macintosh File Type Code(s): Person & email address to contact for further information: Sam Ashmore - srashmo(a)radium.ncsc.mil Intended usage: COMMON Housley, et al. Expires September 23, 2010 [Page 84] Internet-Draft TAMP March 2010 Restrictions on usage: None Author: Sam Ashmore - srashmo(a)radium.ncsc.mil Change controller: IESG B.2. application/tamp-status-response To: ietf-types(a)iana.org Subject: Registration of MIME media type application/ tamp-status-response MIME media type name: application MIME subtype name: tamp-status-response Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: Carries optionally signed status information. Integrity protection is discussed in section 4.2. Interoperability considerations: None Published specification: TBD Applications that use this media type: TAMP clients responding to requests for status information. Additional information: Magic number(s): None File extension(s): .TSR Macintosh File Type Code(s): Person & email address to contact for further information: Sam Ashmore - srashmo(a)radium.ncsc.mil Intended usage: COMMON Restrictions on usage: None Housley, et al. Expires September 23, 2010 [Page 85] Internet-Draft TAMP March 2010 Author: Sam Ashmore - srashmo(a)radium.ncsc.mil Change controller: IESG B.3. application/tamp-update To: ietf-types(a)iana.org Subject: Registration of MIME media type application/tamp-update MIME media type name: application MIME subtype name: tamp-update Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: Carries a signed trust anchor update message. Integrity protection is discussed in section 4.3. Replay detection is discussed in section 6. Interoperability considerations: None Published specification: TBD Applications that use this media type: TAMP clients responding to requests to update trust anchor information. Additional information: Magic number(s): None File extension(s): .TUR Macintosh File Type Code(s): Person & email address to contact for further information: Sam Ashmore - srashmo(a)radium.ncsc.mil Intended usage: COMMON Restrictions on usage: None Author: Sam Ashmore - srashmo(a)radium.ncsc.mil Housley, et al. Expires September 23, 2010 [Page 86] Internet-Draft TAMP March 2010 Change controller: IESG B.4. application/tamp-update-confirm To: ietf-types(a)iana.org Subject: Registration of MIME media type application/ tamp-update-confirm MIME media type name: application MIME subtype name: tamp-update-confirm Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: Carries an optionally signed TAMP update response. Integrity protection is discussed in section 4.4. Interoperability considerations: None Published specification: TBD Applications that use this media type: TAMP clients responding to requests to update trust anchor information Additional information: Magic number(s): None File extension(s): .TUC Macintosh File Type Code(s): Person & email address to contact for further information: Sam Ashmore - srashmo(a)radium.ncsc.mil Intended usage: COMMON Restrictions on usage: None Author: Sam Ashmore - srashmo(a)radium.ncsc.mil Change controller: IESG Housley, et al. Expires September 23, 2010 [Page 87] Internet-Draft TAMP March 2010 B.5. application/tamp-apex-update To: ietf-types(a)iana.org Subject: Registration of MIME media type application/tamp-apex-update MIME media type name: application MIME subtype name: tamp-apex-update Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: Carries a signed request to update an apex trust anchor information. Integrity protection is discussed in section 4.5. Replay detection is discussed in section 6. Interoperability considerations: None Published specification: TBD Applications that use this media type: TAMP clients responding to requests to update an apex trust anchor. Additional information: Magic number(s): None File extension(s): .TAU Macintosh File Type Code(s): Person & email address to contact for further information: Sam Ashmore - srashmo(a)radium.ncsc.mil Intended usage: COMMON Restrictions on usage: None Author: Sam Ashmore - srashmo(a)radium.ncsc.mil Change controller: IESG Housley, et al. Expires September 23, 2010 [Page 88] Internet-Draft TAMP March 2010 B.6. application/tamp-apex-update-confirm To: ietf-types(a)iana.org Subject: Registration of MIME media type application/ tamp-apex-update-confirm MIME media type name: application MIME subtype name: tamp-apex-update-confirm Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: Carries an optionally signed response to an apex update request. Integrity protection is discussed in section 4.6. Interoperability considerations: None Published specification: TBD Applications that use this media type: TAMP clients responding to requests to update an apex trust anchor. Additional information: Magic number(s): None File extension(s): .AUC Macintosh File Type Code(s): Person & email address to contact for further information: Sam Ashmore - srashmo(a)radium.ncsc.mil Intended usage: COMMON Restrictions on usage: None Author: Sam Ashmore - srashmo(a)radium.ncsc.mil Change controller: IESG Housley, et al. Expires September 23, 2010 [Page 89] Internet-Draft TAMP March 2010 B.7. application/tamp-community-update To: ietf-types(a)iana.org Subject: Registration of MIME media type application/ tamp-community-update MIME media type name: application MIME subtype name: tamp-community-update Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: Carries a signed request to update community membership information. Integrity protection is discussed in section 4.7. Replay detection is discussed in section 6. Interoperability considerations: None Published specification: TBD Applications that use this media type: TAMP clients responding to requests to update community membership. Additional information: Magic number(s): None File extension(s): .TCU Macintosh File Type Code(s): Person & email address to contact for further information: Sam Ashmore - srashmo(a)radium.ncsc.mil Intended usage: COMMON Restrictions on usage: None Author: Sam Ashmore - srashmo(a)radium.ncsc.mil Change controller: IESG Housley, et al. Expires September 23, 2010 [Page 90] Internet-Draft TAMP March 2010 B.8. application/tamp-community-update-confirm To: ietf-types(a)iana.org Subject: Registration of MIME media type application/ tamp-community-update-confirm MIME media type name: application MIME subtype name: tamp-community-update-confirm Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: Carries an optionally signed response to a community update request. Integrity protection is discussed in section 4.8. Interoperability considerations: None Published specification: TBD Applications that use this media type: TAMP clients responding to requests to update community membership. Additional information: Magic number(s): None File extension(s): .CUC Macintosh File Type Code(s): Person & email address to contact for further information: Sam Ashmore - srashmo(a)radium.ncsc.mil Intended usage: COMMON Restrictions on usage: None Author: Sam Ashmore - srashmo(a)radium.ncsc.mil Change controller: IESG Housley, et al. Expires September 23, 2010 [Page 91] Internet-Draft TAMP March 2010 B.9. application/tamp-sequence-adjust To: ietf-types(a)iana.org Subject: Registration of MIME media type application/ tamp-sequence-adjust MIME media type name: application MIME subtype name: tamp-sequence-adjust Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: Carries a signed request to update sequence number information. Integrity protection is discussed in section 4.9. Replay detection is discussed in section 6. Interoperability considerations: None Published specification: TBD Applications that use this media type: TAMP clients responding to requests to update sequence number information. Additional information: Magic number(s): None File extension(s): .TSA Macintosh File Type Code(s): Person & email address to contact for further information: Sam Ashmore - srashmo(a)radium.ncsc.mil Intended usage: COMMON Restrictions on usage: None Author: Sam Ashmore - srashmo(a)radium.ncsc.mil Change controller: IESG Housley, et al. Expires September 23, 2010 [Page 92] Internet-Draft TAMP March 2010 B.10. application/tamp-sequence-adjust-confirm To: ietf-types(a)iana.org Subject: Registration of MIME media type application/ tamp-sequence-adjust-confirm MIME media type name: application MIME subtype name: tamp-sequence-adjust-confirm Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: Carries an optionally signed sequence number adjust confirmation message. Integrity protection is discussed in section 4.10. Interoperability considerations: None Published specification: TBD Applications that use this media type: TAMP clients responding to requests to update sequence number information. Additional information: Magic number(s): None File extension(s): .SAC Macintosh File Type Code(s): Person & email address to contact for further information: Sam Ashmore - srashmo(a)radium.ncsc.mil Intended usage: COMMON Restrictions on usage: None Author: Sam Ashmore - srashmo(a)radium.ncsc.mil Change controller: IESG Housley, et al. Expires September 23, 2010 [Page 93] Internet-Draft TAMP March 2010 B.11. application/tamp-error To: ietf-types(a)iana.org Subject: Registration of MIME media type application/tamp-error MIME media type name: application MIME subtype name: tamp-error Required parameters: None Optional parameters: None Encoding considerations: Binary Security considerations: Carries optionally signed error information collecting during TAMP processing. Integrity protection is discussed in section 4.11. Interoperability considerations: None Published specification: TBD Applications that use this media type: TAMP clients processing TAMP messages. Additional information: Magic number(s): None File extension(s): .TER Macintosh File Type Code(s): Person & email address to contact for further information: Sam Ashmore - srashmo(a)radium.ncsc.mil Intended usage: COMMON Restrictions on usage: None Author: Sam Ashmore - srashmo(a)radium.ncsc.mil Change controller: IESG Housley, et al. Expires September 23, 2010 [Page 94] ---- end excerpt from draft-ietf-pkix-tamp-07.txt ------- Thanks, Tim Polk IETF Security Area Director ------ End of Forwarded Message

2 1