- Ietf-types - alvestrand.no

Please review: DRAFT Registration of application/samlmetadata+xml
by Jeff.Hodges＠KingsMountain.com 06 Sep '04

06 Sep '04

<NOTE: Registration of MIME media type application/samlmetadata+xml sstc-saml-2.0-application-samlmetadata-registration-00 Jeff Hodges <Jeff.Hodges(a)Sun.com> 23-Aug-2004 This document is intended to be included in sstc-saml-metadata-2.0-cd-02 (ie the next time [SAMLv2Meta] is rev'd), as an appendix. Please refer to the bibliography below. Please see http://www.w3.org/2002/06/registering-mediatype.html for an overview of the intricities involved when a non-IETF organization registers a MIME media type in the "standards tree" (aka "IETF tree"). The below registration material is intended to satisfy the requirements stated in draft-freed-media-type-reg-01.txt (which superseded draft-freed-mime-p4-04.txt). This "NOTE" is intended to be removed upon copying this document's content into [SAMLv2Meta]. Acknowledgments: Thanks to Ned Freed and Larry Masinter for their comments on a draft of a related registration. The security considerations section leverages that of http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by John Kemp. > To: ietf-types(a)iana.org Subject: Registration of MIME media type application/samlmetadata+xml Introduction This document defines a MIME media type -- application/samlmetadata+xml -- for use with the XML serialization of Security Assertion Markup Language metadata. SAML is a work product of the OASIS Security Services Technical Committee [SSTC]. The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. Using SAML, one can assert that an authentication event pertaining to some subject has occurred and convey said assertion to a relying party, for example. SAML profiles require agreements between system entities regarding identifiers, binding support, endpoints, certificates, keys, and so forth. Such information is treated as metadata by SAML v2.0. [SAMLv2Meta] specifies this metadata, as well as specifying metadata publication and resolution mechanisms. If the publishing protocol permits MIME-based identification of content types, then use of the application/samlmetadata+xml MIME media type is required. MIME media type name: application MIME subtype name: samlmetadata+xml Required parameters: none Optional parameters: charset Same as charset parameter of application/xml [RFC3023]. Encoding considerations: Same as for application/xml [RFC3023]. Security considerations: Per their specification, samlmetadata+xml typed objects do not contain executable content. However, these objects are XML-based [XML], and thus they have all of the general security considerations presented in section 10 of [RFC3023]. SAML metadata [SAMLv2Meta] contains information whose integrity and authenticity is important identity provider and service provider public keys and endpoint addresses, for example. To counter potential issues, the publisher may sign samlmetadata+xml typed objects. Any such signature should be verified by the recipient of the data - both as a valid signature, and as being the signature of the publisher. Additionally, various of the publication protocols, e.g. HTTP-over-TLS/SSL, offer means for ensuring the authenticity of the publishing party and for protecting the metadata in transit. [SAMLv2Meta] also defines prescriptive metadata caching directives, as well as guidance on handling HTTPS redirects, trust processing, server authentication, and related items. For a more detailed discussion of SAML v2.0 metadata and its security considerations, please see [SAMLv2Meta]. For a discussion of overall SAML v2.0 security considerations and specific security-related design features, please refer to the SAML v2.0 specifications listed in the below bibliography. The specifications containing security-specific information are explicitly listed. Interoperability considerations: SAML v2.0 metadata explicitly supports identifying the protocols and versions supported by the identified entities. For example, an identity provider entity can be denoted as supporting SAML v2.0, SAML v1.1 [SAMLv1.1], Liberty ID-FF 1.2 [LAPFF], or even other protocols if they are unambiguously identifiable via URI [RFC2396]. This protocol support information is conveyed via the protocolSupportEnumeration attribute of metadata objects of the RoleDescriptorType. Published specification: [SAMLv2Meta] explicitly specifies use of the application/samlmetadata+xml MIME media type. Applications which use this media type: Potentially any application implementing SAML v2.0, as well as those applications implementing specifications based on SAML, e.g. those available from the Liberty Alliance [LAP]. Additional information: Magic number(s): In general, the same as for application/xml [RFC3023]. In particular, the XML root element of the returned object will be one of <md:EntityDescriptor>, <md:AffiliationDescriptor>, or <md:EntitiesDescriptor>. where "md" maps to the SAML v2.0 metadata namespace: urn:oasis:names:tc:SAML:2.0:metadata File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: This registration is made on behalf of the OASIS Security Services Technical Committee (SSTC) Please refer to the SSTC website for current information on committee chairperson(s) and their contact addresses: http://www.oasis-open.org/committees/security/. Committee members should submit comments and potential errata to the securityservices(a)lists.oasis-open.org list. Others should submit them by filling out the web form located at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=s Additionally, the SAML developer community email distribution list, saml-dev(a)lists.oasis-open.org, may be employed to discuss usage of the application/samlmetadata+xml MIME media type. The "saml-dev" mailing list is publicly archived here: http://lists.oasis-open.org/archives/saml-dev/. To post to the "saml-dev" mailing list, one must subscribe to it. To subscribe, send a message with the single word "subscribe" in the message body, to: saml-dev-request(a)lists.oasis-open.org. Intended usage: COMMON Author/Change controller: The SAML specification sets are a work product of the OASIS Security Services Technical Committee (SSTC). OASIS and the SSTC have change control over the SAML specification sets. Bibliography [LAP] "Liberty Alliance Project". See http://www.projectliberty.org/ [LAPFF] "Liberty Alliance Project: Federation Framework". See http://www.projectliberty.org/resources/ specifications.php#box1 [OASIS] "Organization for the Advancement of Structured Information Systems". See http://www.oasis-open.org/ [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax. IETF RFC 2396, August 1998. Available at http://www.ietf.org/rfc/rfc2396.txt [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types", IETF Request for Comments 3023, January 2001. Available as http://www.rfc-editor.org/rfc/rfc3023.txt [SAMLv1.1] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.1 Specification Set". OASIS Standard 200308, August 2003. Available as http://www.oasis-open.org/committees/download.php /3400/oasis-sstc-saml-1.1-pdf-xsd.zip [SAMLv2.0] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 2.0 Specification Set". WORK IN PROGRESS. Available at http://www.oasis-open.org/committees/security/ [SAMLv2Bind] S. Cantor et al., "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Core] S. Cantor et al., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Meta] S. Cantor et al., Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, August 2004. Document ID sstc-saml-metadata-2.0-cd-01. See http://www.oasis-open.org/committees/security/ [SAMLv2Prof] S. Cantor et al., "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Sec] F. Hirsch et al., "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004, WORK IN PROGRESS. Document ID sstc-saml-sec-consider-2.0-cd-01. See http://www.oasis-open.org/committees/security/ [SSTC] "OASIS Security Services Technical Committee". See http://www.oasis-open.org/committees/security/ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xml, October 2000, Available as http://www.w3.org/TR/REC-xml --- end

2 1

Please review: DRAFT Reg of application/samlassertion+xml
by Jeff.Hodges＠KingsMountain.com 06 Sep '04

06 Sep '04

<NOTE: Registration of MIME media type application/samlassertion+xml sstc-saml-2.0-application-samlassertion-registration-00 Jeff Hodges <Jeff.Hodges(a)Sun.com> 21-Aug-2004 This document supersedes draft-hodges-saml-mediatype-02.txt. It is intended to be included in sstc-saml-bindings-2.0-cd-02 (ie the next time [SAMLv2Bind] is rev'd) as an appendix. Please refer to the bibliography below. For an overview of the intricities involved when a non-IETF organization registers a MIME media type in the "standards tree" (aka "IETF tree"), please see http://www.w3.org/2002/06/registering-mediatype.html. The below registration material is intended to satisfy the requirements stated in draft-freed-media-type-reg-01.txt (which supersedes draft-freed-mime-p4-04.txt). This "NOTE" is intended to be removed upon copying this document's content into [SAMLv2Bind]. Acknowledgments: Thanks to Ned Freed and Larry Masinter for their comments on a prior draft of this registration. The security considerations section leverages that of http://www.iana.org/assignments/media-types/application/vnd.paos+xml, by John Kemp. > To: ietf-types(a)iana.org Subject: Registration of MIME media type application/samlassertion+xml Introduction This document defines a MIME media type -- application/samlassertion+xml -- for use with the XML serialization of SAML (Security Assertion Markup Language) assertions. The SAML specification sets -- [SAMLv1.0], [SAMLv1.1], [SAMLv2.0] -- are work products of the OASIS Security Services Technical Committee [SSTC]. The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. Using SAML, one can assert that an authentication event pertaining to some subject has occured and convey said assertion to a relying party, for example. SAML assertions, which are explicitly versioned, are defined by [SAMLv1Core], [SAMLv11Core], and [SAMLv2Core]. MIME media type name: application MIME subtype name: samlassertion+xml Required parameters: none Optional parameters: charset Same as charset parameter of application/xml [RFC3023]. Encoding considerations: Same as for application/xml [RFC3023]. Security considerations: Per their specification, samlassertion+xml typed objects do not contain executable content. However, SAML assertions are XML-based objects [XML]. As such, they have all of the general security considerations presented in section 10 of [RFC3023], as well as additional ones, since they are explicit security objects. For example, samlassertion+xml typed objects will often contain data that may identify or pertain to a natural person, and may be used as a basis for sessions and access control decisions. To counter potential issues, samlassertion+xml typed objects contain data that should be signed appropriately by the sender. Any such signature must be verified by the recipient of the data - both as a valid signature, and as being the signature of the sender. Issuers of samlassertion+xml objects containing SAMLv2 assertions may also encrypt all, or portions of, the assertions [SAMLv2Core]. In addition, SAML profiles and protocol bindings specify use of secure channels as appropriate. [SAMLv2.0] incorporates various privacy-protection techniques in its design. For example: opaque handles, specific to interactions between specific system entities, are assigned to subjects. The handles are mappable to wider-context identifiers (e.g. email addresses, account identifiers, etc) by only the specific parties. For a more detailed discussion of SAML security considerations and specific security-related design techniques, please refer to the SAML specifications listed in the below bibliography. The specifications containing security-specific information have been explicitly listed for each version of SAML. Interoperability considerations: SAML assertions are explicitly versioned. Relying parties should ensure that they observe assertion version information and behave accordingly. See "Chapter 4 SAML Versioning" in [SAMLv1Core], [SAMLv11Core], or [SAMLv2Core], as appropriate. Published specification: [SAMLv2Bind] explicitly specifies use of the application/samlassertion+xml MIME media type. However, it is conceivable that non-SAMLv2 assertions (i.e. SAMLv1 and/or SAMLv1.1) might in practice be conveyed using SAMLv2 bindings. Applications which use this media type: Potentially any application implementing SAML, as well as those applications implementing specifications based on SAML, e.g. those available from the Liberty Alliance [LAP]. Additional information: Magic number(s): In general, the same as for application/xml [RFC3023]. In particular, the XML root element of the returned object will be <saml:Assertion>, where "saml" maps to a version-specific SAML assertion namespace, as defined by the appropriate SAML "core" specification (see bibliography). In the case of SAMLv2.0, the root element of the returned object may be either <saml:Assertion> or <saml:EncryptedAssertion>, where "saml" maps to the SAMLv2.0 assertion namespace: urn:oasis:names:tc:SAML:2.0:assertion File extension(s): none Macintosh File Type Code(s): none Person & email address to contact for further information: This registration is made on behalf of the OASIS Security Services Technical Committee (SSTC) Please refer to the SSTC website for current information on committee chairperson(s) and their contact addresses: http://www.oasis-open.org/committees/security/. Committee members should submit comments and potential errata to the securityservices(a)lists.oasis-open.org list. Others should submit them by filling out the web form located at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=secur Additionally, the SAML developer community email distribution list, saml-dev(a)lists.oasis-open.org, may be employed to discuss usage of the application/samlassertion+xml MIME media type. The "saml-dev" mailing list is publicly archived here: http://lists.oasis-open.org/archives/saml-dev/. To post to the "saml-dev" mailing list, one must subscribe to it. To subscribe, send a message with the single word "subscribe" in the message body, to: saml-dev-request(a)lists.oasis-open.org. Intended usage: COMMON Author/Change controller: The SAML specification sets are a work product of the OASIS Security Services Technical Committee (SSTC). OASIS and the SSTC have change control over the SAML specification sets. Bibliography [LAP] "Liberty Alliance Project". See http://www.projectliberty.org/ [OASIS] "Organization for the Advancement of Structured Information Systems". See http://www.oasis-open.org/ [RFC3023] M. Murata, S. St.Laurent, D. Kohn, "XML Media Types", IETF Request for Comments 3023, January 2001. Available as http://www.rfc-editor.org/rfc/rfc3023.txt [SAMLv1.0] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.0 Specification Set". OASIS Standard 200205, November 2002. Available as http://www.oasis-open.org/committees/download.php/2290/ oasis-sstc-saml-1.0.zip [SAMLv1Bind] Prateek Mishra et al., "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML)", OASIS, November 2002. Document ID oasis-sstc-saml-bindings-1.0. See http://www.oasis-open.org/committees/security/ [SAMLv1Core] Phillip Hallam-Baker et al., "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)", OASIS, November 2002. Document ID oasis-sstc-saml-core-1.0. See http://www.oasis-open.org/committees/security/ [SAMLv1Sec] Chris McLaren et al., "Security Considerations for the OASIS Security Assertion Markup Language (SAML)", OASIS, November 2002. Document ID oasis-sstc-saml-sec-consider-1.0. See http://www.oasis-open.org/committees/security/ [SAMLv1.1] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 1.1 Specification Set". OASIS Standard 200308, August 2003. Available as http://www.oasis-open.org/committees/download.php/3400/ oasis-sstc-saml-1.1-pdf-xsd.zip [SAMLv11Bind] E. Maler et al. "Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML)". OASIS, September 2003. Document ID oasis-sstc-saml-bindings-1.1. http://www.oasis-open.org/committees/security/ [SAMLv11Core] E. Maler et al. "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)". OASIS, September 2003. Document ID oasis-sstc-saml-core-1.1. http://www.oasis-open.org/committees/security/ [SAMLv11Sec] E. Maler et al. "Security Considerations for the OASIS Security Assertion Markup Language (SAML)". OASIS, September 2003. Document ID oasis-sstc-saml-sec-consider-1.1. http://www.oasis-open.org/committees/security/ [SAMLv2.0] OASIS Security Services Technical Committee, "Security Assertion Markup Language (SAML) Version 2.0 Specification Set". WORK IN PROGRESS. Available at http://www.oasis-open.org/committees/security/ [SAMLv2Bind] S. Cantor et al., "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-bindings-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Core] S. Cantor et al., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-core-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Prof] S. Cantor et al., "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004. Document ID sstc-saml-profiles-2.0-cd-01, WORK IN PROGRESS. See http://www.oasis-open.org/committees/security/ [SAMLv2Sec] F. Hirsch et al., "Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0". OASIS SSTC, August 2004, WORK IN PROGRESS. Document ID sstc-saml-sec-consider-2.0-cd-01. See http://www.oasis-open.org/committees/security/ [SSTC] "OASIS Security Services Technical Committee". See http://www.oasis-open.org/committees/security/ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C.M. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xml, October 2000, Available as http://www.w3.org/TR/REC-xml

3 2

draft-freed-mime-p4-04 is apparently superseded by..
by Jeff Hodges 05 Sep '04

05 Sep '04

draft-freed-mime-p4-05 http://www.ietf.org/internet-drafts/draft-freed-mime-p4-05.txt draft-freed-media-type-reg-01 http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt MartinD or whomever might want to update their very nice page.. How to Register a Media Type with IANA (for the IETF tree) http://www.w3.org/2002/06/registering-mediatype.html thanks, JeffH

4 4

Re: Please review: DRAFT Reg of application/samlassertion+xml
by Jeff.Hodges＠KingsMountain.com 02 Sep '04

02 Sep '04

> At 09:06 04/09/01 -0700, Jeff.Hodges(a)KingsMountain.com wrote: > > >For an overview of the intricities involved when a non-IETF organization > >registers a MIME media type in the "standards tree" (aka "IETF tree"), > >please see http://www.w3.org/2002/06/registering-mediatype.html. > > > Please note that this page is written and intended only for media > types from the W3C. This has been clarified in the title. > It is mainly concerned about synchronizing the W3C Recommendation > Process and the media type registration, and is based on discussion > between W3C and IETF. Other organizations have different processes, > and it is dangerous for them to base on the above document. Your concern is appreciated, thanks. However, I do clearly say "overview", and I believe that your webpage is salient and worth investigating for those folks who are wearing hat(s) of non-IETF stds dvlp org(s) and wishing to register MIME media types, if only to use as a model for determining and documenting the process relative to their non-IETF org. JeffH

1 0

Submission of the application/xop+xml Media Type
by Yves Lafon 02 Sep '04

02 Sep '04

All, The media type is defined in the W3C Candidate Recommandation of "XML-binary Optimized Packaging" [1] Below is a full test version for convenience [2] Please direct comments to xmlp-comments(a)w3.org. Best regards, [1] http://www.w3.org/TR/2004/CR-xop10-20040826/#N103C0 [2] MIME media type name: application MIME subtype name: xop+xml Required parameters: type This parameter conveys the content type associated with the XML serialization of the XOP infoset, including parameters as appropriate. Optional parameters: charset This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in RFC 3023 [RFC3023]. Encoding considerations: Identical to those of "application/xml" as described in RFC 3023 [RFC3023], section 3.2. Security considerations: In addition to application-specific considerations, XOP has the same security considerations described in RFC3023 [RFC3023], section 10. Interoperability considerations: There are no known interoperability issues. Published specification: This document Applications which use this media type: No known applications currently use this media type. Additional information: File extension: XOP Fragment identifiers: Identical to that of "application/xml" as described in RFC 3023 [RFC3023], section 5. Base URI: As specified in RFC 3023 [RFC3023], section 6. Macintosh File Type code: TEXT Person and email address to contact for further information: Mark Nottingham <mnot(a)pobox.com> Intended usage: COMMON Author/Change controller: The XOP specification is a work product of the World Wide Web Consortium's XML Protocol Working Group. The W3C has change control over this specification. -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras."

1 0

RE: Pre review of 3GPP MIME type for RTP payload format
by Magnus Westerlund (KI/EAB) 02 Sep '04

02 Sep '04

Hi Larry, Comments below, prefixed with [mw]. -----Original Message----- From: Larry Masinter To: Magnus Westerlund (KI/EAB) Cc: ietf-types(a)iana.org Sent: 2004-08-16 08:37 Subject: RE: Pre review of 3GPP MIME type for RTP payload format > The problem is that the RTP payload format this defines is capable of > wrapping any other payload format. Yes, the 'application' is the 'application as a wrapping technology'. > As any other payload format > theoretically has any of the media types, this format needs to handle > all of the types. This isn't inconsistent with using 'application'. [mw] Yes, I would agree with you in the general context. However things are not this simple in the RTP usage domain. I will try to explain reasons why RTP payload formats that apply to different media types needs to be registered in multiple media types. [\mw] > So from my perspective, I don't see a problem with removing "Image" and > "application" from the registration. The other three are needed. I think we differ on the meaning of the top level media type. You imagine that you need to use 'image' when the body is an image, and I don't think it is necessary at all. [mw] The fact is that RTP and its signalling do require the registration in the applicable. For RTP there is a clear explanation in RFC 3550 why it is harmful to mix different media types in the same RTP session. Due to this reason also the signalling in SDP does not allow the mixing of multiple media types in the same RTP session. So due to the above restrictions one can not register an single application/rtp.enc.aes128 to secure all the different media top levels. [\mw] I think it is harmful to register multiple media types when one will do nicely. It isn't necessary that every MIME label be completely descriptive of the content, but just that the MIME label contain sufficient information to find the appropriate reciever. [mw] There is actuallly a good thing with registering in each media type for format that applies to one or all. That way one can ensure that a format actually is applicable to that media type. If one only register a single format, then there is not the same foral check that the usage for a certain meda type actually is applicable. For example the audio/RED mime type which we are now registering as text/RED when it has been checked that it is applicable. [\mw] And, since you can't do anything with the content without decrypting it, and leaking information about the content is a concern, why not just use 'application' all the time? Like with ZIP files or PDF files. [mw] In the RTP framework you are required to leak what media type in the signalling path anyway. You will need to secure the signalling path individually to the desired security level. I am sorry that the kinks of the RTP payload format MIME registrations procceduers was not worked out years ago. Today when we have several years of baggage, changing things are difficult. Please take a look at RFC 3555 whith outline the RTP MIME registration procedures. We do know that we will need to probably update this document when the new MIME registration rules are agreed on. [\mw] Cheers Magnus Westerlund

3 4

Re: Request for comments for Media Type registration ofapplication/ccxml+xml
by Al Gilman 31 Aug '04

31 Aug '04

At 3:03 PM +0900 7/28/04, Martin Duerst wrote: >At 13:05 04/07/27 -0700, RJ Auburn wrote: > >>On 07/21/2004 22:03, "Larry Masinter" <LMM(a)acm.org> wrote: >> >>> These comments are as much about the general "IETF MIME type >>> registration from W3C recommendation" as they are about this >>> particular registration: >> >> >>Martin: Would you be the person to handle/address the general issues? > >Yes. For everybody's information, RJ is following the procedure laid >out >Because he is the first to do so, this is a very good case to see >where we have to tweak that description. I have already made two >additions: >1) Added a sentence "Make sure that this part of the specification > is readable on its own, without the context of the specification." > [for further details, a good example is probably better than a > lot of explanations] >2) Added a sentence "To make it easier for your WG to track comments > on the Media Type section, you may cross-post the comments list > for your specification." > [I want to leave this to the group for the moment. They have to > show that they addressed comments to the IESG, so having that > documented in a last call table may have advantages and > disadvantages.] > >Also, I'm planning to add some pointers to examples to the above >description, once we have them. That should make it easier for >others to do this. > >> > Your translation from HTML to ASCII left out line breaks >>> before heading lines, which made your template hard >>> to read. >> >>If needed I can resubmit a nicer looking version. Let me know... > >I guess that can wait for the next time you send something anyway, >but I hope this will be soon. > >> >> Published specification: >>>> >>>> This media type registration is for CCXML documents as >>>> described by this specification. >>> >>> I'm not 100% sure if this is necessary, but I'd expect >>> if the template were to appear elsewhere to see >>> a bibliographic citation, e.g., >>> >>> "Voice Browser Call Control: CCXML Version 1.0", W3C >>> Working Draft, 30 April 2004, W3C, >>> >>> Is "this specification" (or the whole specification) precise >>> enough? In some other cases, a single W3C recommendation defines >>> many different data types. Perhaps it would be useful to >>> say, somewhere, e.g., that the MIME type refers to XML bodies that >>> conform to the DTD/Schema referenced in Appendix B and C and >>> interpreted by the rules in the cited specification. >> >> >>Pointing at the schema/dtd sections seems reasonable. How is this for text: >> >>Published specification: >> This media type registration is for XML bodies that >> conform to the DTD/Schema referenced in Appendix B and C and >> interpreted by the rules this specification > >'this specification' -> 'of this specification' > >> >> Person & email address to contact for further information: >>>> >>>> RJ Auburn, <rj(a)voxeo.com>. >>> >>> Should there be a W3C contact as well? >> >> >>Dave/Max/Martin: Thoughts? > >Adding the name of a staff contact or so might be a good idea. > >> >> Intended usage: >>>> >>>> COMMON >>>> Author/Change controller: >>>> >>>> The CCXML specification is a work product of the World Wide Web >>> Consortium's >>>> Voice Browser Working Group. The W3C has change control over these >>>> specifications. >>> >>> Or perhaps the W3C contact address should be listed here. >> >>Dave/Max/Martin: Thoughts? > >The W3C is 'on the Web', not at a particular physical location. >This kind of wording has been used in some previous registrations, >and should be okay. Actually, Martin, the W3C should come up with something better. This is a detail of the "life after Rec[ommendation status is achieved]" that I am not aware we have laid out adequately. There is a slight problem because the W3C has studiously avoided being a legal entity which could be identified in standard X.500 terms. Do you have a technical comment? W3C technical reports include email addresses where readers should send technical comments. </quote> The Consortium has also assiduously avoided promising to answer questions about its utterances, other than that one may post 'comments' in the above manner. Clearly a 'comment' alleging that there is an inconsistency in the provisions of a specification, if read and found to be accurate, may result in something being added to the errata for a document. I would suggest that the 'comments to' email address be included in the contact information provided in a MIME type registration request. As far as identifying The Consortium it should suffice to use the URI as identification in this context. It would be helpful, but probably not required by the IETF pro-formas, to also allude to the process for change control by a reference to the W3C Process Document identified Al >Regards, Martin.

1 0

MIME-type Review Request: draft-ietf-simple-event-list-05.txt
by Allison Mankin 30 Aug '04

30 Aug '04

This is a request for MIME-type review for this document http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-05.txt wherein is found the registration of application/rlmi+xml Please send comments to both the ietf-types list and the cc recipients listed on this message. Thank you, Allison

2 1

Re-Send: MIME-type Review Request: draft-ietf-simple-event-list-05.txt
by Allison Mankin 30 Aug '04

30 Aug '04

Trying this again, in case the first one did not go out ------- Forwarded Message Date: Mon, 30 Aug 2004 09:19:10 -0700 From: Allison Mankin <mankin(a)psg.com> To: ietf-types(a)alvestrand.no cc: "Ted Hardie" <hardie(a)qualcomm.com>, "Scott Hollenbeck" <sah(a)428cobrajet.net>, "Allison Mankin" <mankin(a)psg.com> This is a request for MIME-type review for this document http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-05.txt wherein is found the registration of application/rlmi+xml Please send comments to both the ietf-types list and the cc recipients listed on this message. Thank you, Allison ------- End of Forwarded Message

1 0

Re: Request for comments for Media Type registration ofapplication/ccxml+xml
by Al Gilman 30 Aug '04

30 Aug '04

At 3:03 PM +0900 7/28/04, Martin Duerst wrote: >At 13:05 04/07/27 -0700, RJ Auburn wrote: > >>On 07/21/2004 22:03, "Larry Masinter" <LMM(a)acm.org> wrote: >> >>> These comments are as much about the general "IETF MIME type >>> registration from W3C recommendation" as they are about this >>> particular registration: >> >> >>Martin: Would you be the person to handle/address the general issues? > >Yes. For everybody's information, RJ is following the procedure laid >out >Because he is the first to do so, this is a very good case to see >where we have to tweak that description. I have already made two >additions: >1) Added a sentence "Make sure that this part of the specification > is readable on its own, without the context of the specification." > [for further details, a good example is probably better than a > lot of explanations] >2) Added a sentence "To make it easier for your WG to track comments > on the Media Type section, you may cross-post the comments list > for your specification." > [I want to leave this to the group for the moment. They have to > show that they addressed comments to the IESG, so having that > documented in a last call table may have advantages and > disadvantages.] > >Also, I'm planning to add some pointers to examples to the above >description, once we have them. That should make it easier for >others to do this. > >> > Your translation from HTML to ASCII left out line breaks >>> before heading lines, which made your template hard >>> to read. >> >>If needed I can resubmit a nicer looking version. Let me know... > >I guess that can wait for the next time you send something anyway, >but I hope this will be soon. > >> >> Published specification: >>>> >>>> This media type registration is for CCXML documents as >>>> described by this specification. >>> >>> I'm not 100% sure if this is necessary, but I'd expect >>> if the template were to appear elsewhere to see >>> a bibliographic citation, e.g., >>> >>> "Voice Browser Call Control: CCXML Version 1.0", W3C >>> Working Draft, 30 April 2004, W3C, >>> >>> Is "this specification" (or the whole specification) precise >>> enough? In some other cases, a single W3C recommendation defines >>> many different data types. Perhaps it would be useful to >>> say, somewhere, e.g., that the MIME type refers to XML bodies that >>> conform to the DTD/Schema referenced in Appendix B and C and >>> interpreted by the rules in the cited specification. >> >> >>Pointing at the schema/dtd sections seems reasonable. How is this for text: >> >>Published specification: >> This media type registration is for XML bodies that >> conform to the DTD/Schema referenced in Appendix B and C and >> interpreted by the rules this specification > >'this specification' -> 'of this specification' > >> >> Person & email address to contact for further information: >>>> >>>> RJ Auburn, <rj(a)voxeo.com>. >>> >>> Should there be a W3C contact as well? >> >> >>Dave/Max/Martin: Thoughts? > >Adding the name of a staff contact or so might be a good idea. > >> >> Intended usage: >>>> >>>> COMMON >>>> Author/Change controller: >>>> >>>> The CCXML specification is a work product of the World Wide Web >>> Consortium's >>>> Voice Browser Working Group. The W3C has change control over these >>>> specifications. >>> >>> Or perhaps the W3C contact address should be listed here. >> >>Dave/Max/Martin: Thoughts? > >The W3C is 'on the Web', not at a particular physical location. >This kind of wording has been used in some previous registrations, >and should be okay. Actually, Martin, the W3C should come up with something better. This is a detail of the "life after Rec[ommendation status is achieved]" that I am not aware we have laid out adequately. There is a slight problem because the W3C has studiously avoided being a legal entity which could be identified in standard X.500 terms. Do you have a technical comment? W3C technical reports include email addresses where readers should send technical comments. </quote> The Consortium has also assiduously avoided promising to answer questions about its utterances, other than that one may post 'comments' in the above manner. Clearly a 'comment' alleging that there is an inconsistency in the provisions of a specification, if read and found to be accurate, may result in something being added to the errata for a document. I would suggest that the 'comments to' email address be included in the contact information provided in a MIME type registration request. As far as identifying The Consortium it should suffice to use the URI as identification in this context. It would be helpful, but probably not required by the IETF pro-formas, to also allude to the process for change control by a reference to the W3C Process Document identified Al >Regards, Martin.

1 0