September 2009 - Ietf-types

Registration of media type application/ttaf+xml
by Philippe Le Hegaret 26 Aug '10

26 Aug '10

The following media type registration will be submitted to the IESG for review, approval, and registration with IANA (as per [1]). At this point, we would appreciate comments on this registration information. If you see any problems, please let us know. Regards, Philippe [1] http://www.w3.org/2002/06/registering-mediatype [[ This appendix registers a new MIME media type, "application/ttaf+xml" in conformance with [1144]BCP 13 and [1145]W3CRegMedia. The information in this appendix is being submitted to the Internet Engineering Steering Group (IESG) for review, approval, and registration with the Internet Assigned Numbers Authority (IANA). [1144] http://www.ietf.org/rfc/rfc4288.txt [1145] http://www.w3.org/2002/06/registering-mediatype.html MIME media type name: application MIME subtype name: ttaf+xml Required parameters: None. Optional parameters: The encoding of a TT AF document must be determined by the XML encoding declaration. This has identical semantics to the application/xml media type in the case where the charset parameter is omitted, as specified in [1146][XML Media], Sections 8.9, 8.10 and 8.11. The document profile of a TT AF document may be specified using an optional profile parameter, which, if specified, the value of which must adhere to the syntax and semantics of ttp:profile parameter defined by Section [1147]6.2.8 ttp:profile of the published specification. Encoding considerations: Same for application/xml. See [1148][XML Media], Section 3.2. Restrictions on usage: None. Security considerations: As with other XML types and as noted in [1149][XML Media] Section 10, repeated expansion of maliciously constructed XML entities can be used to consume large amounts of memory, which may cause XML processors in constrained environments to fail. In addition, because of the extensibility features for TT AF and of XML in general, it is possible that "application/ttaf+xml" may describe content that has security implications beyond those described here. However, if the processor follows only the normative semantics of the published specification, this content will be outside TT AF namespaces and may be ignored. Only in the case where the processor recognizes and processes the additional content, or where further processing of that content is dispatched to other processors, would security issues potentially arise. And in that case, they would fall outside the domain of this registration document. Interoperability considerations: The published specification describes processing semantics that dictate behavior that must be followed when dealing with, among other things, unrecognized elements and attributes, both in TT AF namespaces and in other namespaces. Because TT AF is extensible, conformant "application/ttaf+xml" processors must expect that content received is well-formed XML, but it cannot be guaranteed that the content is valid to a particular DTD or Schema or that the processor will recognize all of the elements and attributes in the document. Published specification: This media type registration is extracted from Appendix [1150]D Media Type Registration of the [1151]Timed Text (TT) Authoring Format 1.0 - Distribution Format Exchange Profile (DFXP) specification. [1151] http://www.w3.org/TR/ttaf1-dfxp/ Additional information: None. Person & email address to contact for further information: Glenn Adams (public-tt(a)w3.org) Intended usage: COMMON Author/Change controller: The published specification is a work product of the World Wide Web Consortium's Timed Text (TT) Working Group. The W3C has change control over this specification. ]] http://www.w3.org/TR/ttaf1-dfxp/#media-type-registration

7 9

Fwd: New Version Notification for draft-murata-kohn-lilley-xml-03
by Chris Lilley 02 Oct '09

02 Oct '09

This is a forwarded message From: IETF I-D Submission Tool <idsubmission(a)ietf.org> To: chris(a)w3.org Date: Thursday, September 24, 2009, 5:56:50 PM Subject: New Version Notification for draft-murata-kohn-lilley-xml-03 ===8<==============Original message text=============== A new version of I-D, draft-murata-kohn-lilley-xml-03.txt has been successfuly submitted by Chris Lilley and posted to the IETF repository. Filename: draft-murata-kohn-lilley-xml Revision: 03 Title: XML Media Types Creation_date: 2009-09-24 WG ID: Independent Submission Number_of_pages: 49 Abstract: This document standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while deprecating text/xml and text/ xml-external-parsed-entity. This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. Major differences from [RFC3023] are deprecation of text/xml and text/xml-external-parsed-entity, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, mention of the XPointer Registry, and updating of many references. The IETF Secretariat. ===8<===========End of original message text=========== -- Chris Lilley mailto:chris@w3.org Technical Director, Interaction Domain W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG

6 19

Re: New Version Notification for draft-murata-kohn-lilley-xml-03
by Julian Reschke 30 Sep '09

30 Sep '09

MURATA Makoto wrote: >> So how about changing it just for the HTTP transport then? > > You are proposing to fix HTTP 1.1. Then, you would need to write an > internet draft which would obsolete RFC 2068 and have it approved > by IESG. > ... Actually, it would be RFC2616, not RFC2068. Furthermore, we're actually doing this in the IETF HTTPbis Working Group. So let's rephrase it... do you have an opinion whether an update to HTTP/1.1 *should* make this change? BR, Julian

2 1

Re: Fwd: New Version Notification for draft-murata-kohn-lilley-xml-03
by Julian Reschke 29 Sep '09

29 Sep '09

Julian Reschke wrote: > Chris Lilley wrote: >> ... >> which also brings advice on the use of the charset parameter into line >> with current practice. In brief, the charset parameter should only be >> added if it agrees with the xml encoding declaration. In the absence >> of an explicit charset parameter, the encoding specified by the xml >> encoding declaration is used. (This is a change from RFC 3023, which >> required enforcing us-ascii in that case). >> ... > > Clarifying... this appears to apply only to application/xml, not > text/xml, right? > ... Furthermore, this was already the case in RFC 3023, so is there any change at all? BR, Julian

3 2

[Fwd: WGLC: draft-ietf-mmusic-rfc2326bis-22]
by Magnus Westerlund 23 Sep '09

23 Sep '09

Hi, This document contains one media type (text/parameters) that we appreciate comments on before the end of the WG last call on the 19th of October. The registration is present in section 22.16. Thanks Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund(a)ericsson.com ----------------------------------------------------------------------

1 0

Re: [sipcore] When to use SIP INFO and SIP INFO-Package
by Eric Burger 23 Sep '09

23 Sep '09

How about this: 1. If someone tries to register a MIME type that will "only" be used for SIP, there is a near 100% likelihood the registration will not pass expert review. Thus you will not have a standard INFO usage. Dean explains why: MIME describes multimedia content. MIME does not describe multimedia use. 2. If someone tries to document a *new* legacy use of INFO that does not use the INFO Framework, there is a near 100% likelihood the document will neither pass expert review nor succeed as an individual informational submission, as the INFO Framework draft makes clear why such documentation may harm the Internet. [Old legacy usages were encouraged to be published, but the only usage that I know of that anyone will publish the IETF has not published yet is MSML, and that is stuck behind two drafts in final, final edits in MEDIACTRL.] 3. IETF will use the INFO Framework for all new INFO usages. Any proprietary use of INFO that does not use the INFO Framework will not be an IETF standard. 4. 3GPP (IMS) will use the INFO Framework. Any proprietary use of INFO that does not use the INFO Framework will not be an IMS standard. 5. All of your competitors will do their best to advertise how your product is totally proprietary and is likely to fail in the field. Moreover, your competitors will advertise how your product can harm the Internet. Finally, if someone *does* register your "magic MIME type", which is something that is quite possible to happen, *YOUR* customers will have to replace / upgrade / remove *YOUR* equipment. Most customers in the telecom space will see that and immediately tell you to build to the standards. Said differently, your product managers will not be very happy with someone who suggests one builds a product one cannot sell or even give away. Given the above, like many people have said, the legacy INFO method "works," in that you can build a non-interoperable, non-standard, totally proprietary, should not be connected to the Internet product. I would also offer such products are a little bit outside the charter of the IETF. We work to build interoperable, standards-based, open, Internet products that people can use safely. Even 3GPP and the ITU-T, for all of the ills many in the IETF would accuse them of, would not consider such a proposal. On Sep 22, 2009, at 8:54 PM, Linyi TIAN wrote: > Hi, Dean Willis, et al. > > I have to say I like your answers which clarify my doubts. May I > suggest > adding some words in " 6. Legacy Uses of INFO" to clarify the new > SIP INFO > Package approach and Content Type Approach? Maybe in the introduction > section we can add more information about the Content Type approach. > I mean > not only talking about the JPEG example. Even in controlled Content- > Type > there maybe issues too as Dean said. > > Current working in introduction section leads me to think about new > method > is only applicable for not-controlled Conent-Type. > > Quote from Dean's email, rewording maybe > needed > --------------------------------------------------------------------- > The MIME type model defines only "what an object is", not "how the > object can be used". To negotiate around "how the object will be used > in this application", we need a higher-level of specification and > negotiation. IN SIP INFO messages, the INFO package definition > provides that level of specification and negotiation. > > in countless application scenarios that the MIME type registration > has no > way of predicting or > controlling. To constrain this diversity in a useful way in the > context of NOTIFY messages within the SIP protocol, we have > historically use event packages, and found this approach to work quite > well. Going forward, in the context of INFO messages within the SIP > protocol, we will use INFO packages for the same reasons. > > Cheers, > Linyi > > -----Original Message----- > From: sipcore-bounces(a)ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > Of Dean Willis > Sent: Wednesday, September 23, 2009 2:40 AM > To: tianlinyi 34932 > Cc: 'Sanjay Sinha (sanjsinh)'; sipcore(a)ietf.org > Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package > > > On Sep 22, 2009, at 10:26 AM, tianlinyi 34932 wrote: > >> Hi, Paul >> >> As i said there is specification clearly states the usage of Content >> type and a registration with this Content Type will be provided. The >> specification will also mention how it will be used in SIP INFO, why >> it is still un-specified? >> >> For example, if 3GPP defines the content type and its usage with SIP >> INFO in a specification why INFO package hearder should be used? I >> didn't see any IOP problem on this approach. >> > > > If 3GPP were to define a new MIME type that is only used in SIP INFO > messages, then you are correct in that the INFO package framework > would add little value. > > However, this is not how MIME types work. > > The MIME type model defines only "what an object is", not "how the > object can be used". To negotiate around "how the object will be used > in this application", we need a higher-level of specification and > negotiation. IN SIP INFO messages, the INFO package definition > provides that level of specification and negotiation. > > The MIME registration process doesn't register things like "This MIME > type can only be used in a SIP INFO message in accordance with the > foobar application as documented in 3GPP TS 99.411." And if somebody > tried to register such a restricted MIME type, I'd hope the ietf-types > people would say "no." Of course, there's no guarantee that no > broken types are going to be registered (especially in vendor trees), > but certainly the majority of existing types aren't broken like this. > Once a type is defined, objects os that type can br transported in > email, HTTP requests, SIP INFO, NOTIFY, and other requests messages, > stored in Windows registries, and so on, in countless application > scenarios that the MIME type registration has no way of predicting or > controlling. To constrain this diversity in a useful way in the > context of NOTIFY messages within the SIP protocol, we have > historically use event packages, and found this approach to work quite > well. Going forward, in the context of INFO messages within the SIP > protocol, we will use INFO packages for the same reasons. > > -- > Dean > > _______________________________________________ > sipcore mailing list > sipcore(a)ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore(a)ietf.org > https://www.ietf.org/mailman/listinfo/sipcore

2 1