From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Tue Jan 3 16:22:39 2006 Subject: Request for guidance on MIME and media types In-Reply-To: <7241C066-2CFF-11D8-8692-00039396E15A@bea.com> References: <7241C066-2CFF-11D8-8692-00039396E15A@bea.com> Message-ID: <20031228193043.GA6372@mauzo.mauzo.dyndns.org> At 4pm on 12/12/03 you (Mark Nottingham) wrote: > Note that a specification is being prepared that allows for > the use of a similar "resolve the URI to insert binary > characters" idiom in non-SOAP scenarios. The general > technique is documented at [3] under the working title "MTOM > Inclusion Format For You (MIFFY)", a title that will almost > surely change due to copyright issues. The proposed > application/soap_mtom+xml media type is thus a specific > example of the so-called Miffy class of encodings. We propose > that a media type be assigned to each such use of Miffy, with > application/soap_mtom+xml being assigned as the name for the > application of Miffy to SOAP envelopes. I entirely agree that a separate MIME type is appropriate; however, I would suggest a more generic name be used, such as application/soap+miffy+xml, with +miffy being generally used for application-of-Miffy-to-foo types. Ben -- If you put all the prophets, | You'd have so much more reason Mystics and saints | Than ever was born In one room together, | Out of all of the conflicts of time. ben@morrow.me.uk |----------------+---------------| The Levellers, 'Believers' From: lists at unknown.nu (Kim Scarborough) Date: Sun Dec 21 20:54:10 2003 Subject: Proposed Registration of MIME media type application/vnd.wordperfect Message-ID: > What is the relationship of this to > http://www.iana.org/assignments/media-types/application/wordperfect5.1 > ? Well, the problem with that was that they appended the version string on the end of the name, so nobody uses it anymore (WordPerfect is up to version 11 now--5.1 was only for DOS and Unix CLI). It's too bad it was registered that way, but it's too late now, so I figured I'd submit this. Also, RFC 2048 encourages re-registering grandfathered media types, so what the heck. -- ------------------------------------------------------------------------------- Kim Scarborough http://www.unknown.nu/kim/ ------------------------------------------------------------------------------- >From mark.nottingham@bea.com Sat Dec 13 01:01:14 2003 From: mark.nottingham at bea.com (Mark Nottingham) Date: Sun Dec 28 19:33:32 2003 Subject: Request for guidance on MIME and media types Message-ID: <7241C066-2CFF-11D8-8692-00039396E15A@bea.com> The W3C XML Protocol Working Group is currently working on the Message Transmission Optimisation Mechanism (MTOM)[1], which allows more efficient transmission of SOAP envelopes [2] by changing their on-the-wire XML serialisation. Registration of the "application/soap+xml" media type is currently under way, so that SOAP envelopes (i.e. the XML construct that SOAP defines) can be identified in MIME and MIME-like systems. We anticipate the need to likewise identify MTOM messages in these systems, and would like to solicit guidance about the best way to do so. Whereas the XML 1.0 serialisation of SOAP is self-contained, MTOM serialisation will only use XML for a subset of the envelope data. Other portions of the envelope will be transmitted in separate binary entities, typically but not necessarily in a multipart/related MIME message, and those entities will be referenced with URIs from the envelope (which, when using multipart/related, would reside in the root part). A simplistic example might be; ---8<--- MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=application/soap_mtom+xml; start="" --MIME_boundary Content-Type: application/soap_mtom+xml Content-Transfer-Encoding: 8bit Content-ID: --MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: [binary image] --MIME_boundary-- ---8<--- Which could be transformed to this XML - ---8<--- [base64-encoded image] ---8<--- The XML that is transmitted by MTOM is thus distinct from application/soap+xml in at least the following respects: * It contains some but not all of the envelope data. Indeed, in the common case where multipart MIME is used, it's the entire package that conveys the same information as application/soap+xml. * Its semantics are different from those of a SOAP envelope. The usual semantic for a SOAP envelope is to apply the SOAP processing model; the semantics of an MTOM envelope are to to resolve the link URIs to create a new Infoset, which is in turn processable by the SOAP model. Therefore, it appears that the application/soap+xml media type, as currently defined, is not appropriate to describe the XML format created by MTOM. We've considered several possible alternatives, including 1) use of a HTTP content-coding (which we rejected, both because content-codings are a HTTP-specific mechanism, whereas we intend to use this encoding in other protocols, possibly including MIME-based protocols, and because doing so would require labelling the HTTP entity with an "application/soap+xml" media type, which would mask the presence of multipart MIME), and 2) a MIME content-transfer-encoding (which we rejected because registration of new CTEs is discouraged by RFC2045). Therefore, we believe that it would be most suitable to register a new media type, e.g., "application/soap_mtom+xml". This media type would identify the XML pre-MTOM processing (i.e., with the URIs to be referenced still embedded), possibly (but not necessarily) located inside a multipart/related package. Note that a specification is being prepared that allows for the use of a similar "resolve the URI to insert binary characters" idiom in non-SOAP scenarios. The general technique is documented at [3] under the working title "MTOM Inclusion Format For You (MIFFY)", a title that will almost surely change due to copyright issues. The proposed application/soap_mtom+xml media type is thus a specific example of the so-called Miffy class of encodings. We propose that a media type be assigned to each such use of Miffy, with application/soap_mtom+xml being assigned as the name for the application of Miffy to SOAP envelopes. We would appreciate any input as to whether this is the most appropriate way to flag the use of an alternate serialisation of an XML format in MIME, and/or pointers to guidance on this matter. 1. http://www.w3.org/TR/soap12-mtom/ 2. http://www.w3.org/TR/soap12-part0/ 3. http://www.w3.org/mid/DD037726-2236-11D8-836E-00039396E15A@bea.com -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems From: lists at unknown.nu (Kim Scarborough) Date: Tue Jan 3 16:22:39 2006 Subject: Proposed Registration of MIME media type application/vnd.wordperfect Message-ID: > What is the relationship of this to > http://www.iana.org/assignments/media-types/application/wordperfect5.1 > ? Well, the problem with that was that they appended the version string on the end of the name, so nobody uses it anymore (WordPerfect is up to version 11 now--5.1 was only for DOS and Unix CLI). It's too bad it was registered that way, but it's too late now, so I figured I'd submit this. Also, RFC 2048 encourages re-registering grandfathered media types, so what the heck. -- ------------------------------------------------------------------------------- Kim Scarborough http://www.unknown.nu/kim/ ------------------------------------------------------------------------------- From: LMM at acm.org (Larry Masinter) Date: Sun Dec 21 08:25:54 2003 Subject: Proposed Registration of MIME media type application/vnd.wordperfect In-Reply-To: <3FE22232.8080006@unknown.nu> Message-ID: <000701c3c793$a0fc38f0$6701a8c0@MasinterT40> What is the relationship of this to http://www.iana.org/assignments/media-types/application/wordperfect5.1 ? From: LMM at acm.org (Larry Masinter) Date: Tue Jan 3 16:22:39 2006 Subject: Proposed Registration of MIME media type application/vnd.wordperfect In-Reply-To: <3FE22232.8080006@unknown.nu> Message-ID: <000701c3c793$a0fc38f0$6701a8c0@MasinterT40> What is the relationship of this to http://www.iana.org/assignments/media-types/application/wordperfect5.1 ? From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Tue Jan 3 16:22:39 2006 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <4.2.0.58.J.20031219133801.06ffa768@localhost> References: <20031220000621.1347.MURATA@hokkaido.email.ne.jp> <4.2.0.58.J.20031219133801.06ffa768@localhost> Message-ID: <20031220230150.134C.MURATA@hokkaido.email.ne.jp> > There are two separate issues: > 1) Does a registration allow the 'charset' parameter or not. > 2) Does an actual entity have the 'charset' parameter or not. > > It is not totally clear to me which one of these you are talking above. 1) > In my opinion, it is highly preferable that all registrations > allow the 'charset' parameter, to avoid a patchwork. The draft > should contain some justification for this. RFC 3023 already provides a registration template which introduces the charset parameter. But the recommendation to introduce the charset parameter is a SHOULD rather than a MUST. People read RFC 3023 but they intentionally dropped the charset. I studied existing +xml media types registered at IANA. Here is the result. 1. IETF tree With the exception of application/cnrp+xml, all +xml media types have the charset parameter. 1) beep+xml [RFC3080] This keeps the charset parameter. 2) cnrp+xml [RFC3367] This omits the charset parameter. Not restricted to UTF-8. 3) cpl+xml [RFCXXXX] http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-08.txt This keeps the charset parameter. 4) pidf+xml [RFC-ietf-impp-cpim-pidf-08.txt] http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-08.txt This keeps the charset parameter. 5) reginfo+xml [RFC-ietf-sipping-reg-event-00.txt] http://www.ietf.org/internet-drafts/draft-ietf-sipping-reg-event-00.txt This keeps the charset parameter. 6) watcherinfo+xml [RFC-ietf-simple-winfo-format-04.txt] http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-04.txt This keeps the charset parameter. 7) xhtml+xml [RFC3236] http://www.rfc-editor.org/rfc/rfc3236.txt This keeps the charset parameter. 2. Vendor tree Only two media types have the charset parameter. Since media types in the vendor tree do not always have accompanying documents, we do not know if there are good reasons to omit the charset. 1) vnd.criticaltools.wbs+xml [Spiller] http://www.iana.org/assignments/media-types/application/vnd.criticaltools.wbs+xml This omits the charset parameter. The details of this structure are proprietary to Critical Tools, Inc. 2) vnd.irepository.package+xml [Knowles] http://www.iana.org/assignments/media-types/application/vnd.irepository.package+xml This omits the charset parameter. Use of this MIME type is limited to users of Lucidoc and associated document management tools published by iRepository.net, Inc. 3) vnd.liberty-request+xml [McDowell] http://www.iana.org/assignments/media-types/application/vnd.liberty-request+xml This omits the charset parameter. 4) vnd.llamagraphics.life-balance.exchange+xml [White] http://www.iana.org/assignments/media-types/application/vnd.llamagraphics.life-balance.exchange+xml This keeps the charset parameter. 5) vnd.mozilla.xul+xml [McDaniel] http://www.iana.org/assignments/media-types/application/vnd.mozilla.xul+xml This keeps the charset parameter. 6) vnd.pwg-xhtml-print+xml [Wright] http://www.iana.org/assignments/media-types/application/vnd.pwg-xhtml-print+xml This omits the charset parameter. 7) vnd.wv.csp+xml [Ingimundarson] http://www.iana.org/assignments/media-types/application/vnd.wv.csp+xml This omits the charset parameter. They wrote "No parameters are required - covered by client-server capability negotiation." 8) vnd.wv.csp+wbxml [Salmi] http://www.iana.org/assignments/media-types/application/vnd.wv.csp+wbxml This omits the charset parameter. They wrote "No parameters are required since WV capability negotiation covers this." 9) vnd.wv.ssp+xml [Ingimundarson] http://www.iana.org/assignments/media-types/application/vnd.wv.ssp+xml This omits the charset parameter. > As for whether the actual entity should come with a 'charset' > parameter, we should also have a discussion of the various > issues in the draft. > > > >By the way, "The Standard Hex Format" uses UTF-8 only. > > > >http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt > > I have not found 'UTF-8' anywhere in this document, so I'm not > sure where you saw this restriction. I am afraid that I made a mistake. We have discussed this issue in the mailing list, but nothing is written down yet. > Another one is > http://www.ietf.org/internet-drafts/draft-sbml-media-type-02.txt. > > This was approved by the IESG yesterday, so I guess it's too late > to try to change it. In practice, I very much hope that no implementation > will reject sbml data that comes with a redundant charset=utf-8. Now we have two exceptions in the IETF tree. Practically, what can we do? Cheers, -- MURATA Makoto From: duerst at w3.org (Martin Duerst) Date: Tue Jan 3 16:22:39 2006 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <20031220000621.1347.MURATA@hokkaido.email.ne.jp> References: <4.2.0.58.J.20031218112549.00a93ad0@localhost> <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031218112549.00a93ad0@localhost> Message-ID: <4.2.0.58.J.20031219133801.06ffa768@localhost> Hello Makoto, At 00:20 03/12/20 +0900, MURATA Makoto wrote: >On Thu, 18 Dec 2003 11:30:44 -0500 >Martin Duerst wrote: > > > There is some work starting on updating RFC 3023, and we hope that > > we can use it to document the issues and questions that have > > come up on the list. Chris has volunteered to coauthor, and I'll > > help from the sidelines. Probably having all the information together > > in one place, is better than having some of the information separated out. > >As a co-author, I also agree to add some guidelines for the omission of the >charset parameter. Chris and I will start this work shortly. We are looking forward to this! >When a media type uses UTF-8 only, I can agree to omit the charset >parameter. "UTF-8" is already a recommended policy >(http://www.w3.org/TR/charmod/#sec-UniqueEncoding). I do not see strong >reasons to specify charset="utf-8" always. However, even in this case, I >am sympathetic to Martin's worry ("we start to get into a patchwork"). >In all other cases, I do not want to allow omission of the charset >parameter. How do others feel? There are two separate issues: 1) Does a registration allow the 'charset' parameter or not. 2) Does an actual entity have the 'charset' parameter or not. It is not totally clear to me which one of these you are talking above. In my opinion, it is highly preferable that all registrations allow the 'charset' parameter, to avoid a patchwork. The draft should contain some justification for this. As for whether the actual entity should come with a 'charset' parameter, we should also have a discussion of the various issues in the draft. >By the way, "The Standard Hex Format" uses UTF-8 only. > >http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt I have not found 'UTF-8' anywhere in this document, so I'm not sure where you saw this restriction. The document contains: >>>>>>>> 9.1 Optional parameters none. There is no charset parameter. Character handling has identical semantics to the case where the charset parameter of the "application/xml" media type is omitted, as described in RFC3023 [4]. >>>>>>>> I think this should be fixed to reinstate the charset parameter as discussed on this mailing list. Another one is http://www.ietf.org/internet-drafts/draft-sbml-media-type-02.txt. This was approved by the IESG yesterday, so I guess it's too late to try to change it. In practice, I very much hope that no implementation will reject sbml data that comes with a redundant charset=utf-8. Regards, Martin. From: distobj at acm.org (Mark Baker) Date: Fri Dec 19 18:26:36 2003 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <20031220000621.1347.MURATA@hokkaido.email.ne.jp>; from murata@hokkaido.email.ne.jp on Sat, Dec 20, 2003 at 12:20:01AM +0900 References: <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031218112549.00a93ad0@localhost> <20031220000621.1347.MURATA@hokkaido.email.ne.jp> Message-ID: <20031219122429.L7952@www.markbaker.ca> On Sat, Dec 20, 2003 at 12:20:01AM +0900, MURATA Makoto wrote: > However, even in this case, I > am sympathetic to Martin's worry ("we start to get into a patchwork"). > In all other cases, I do not want to allow omission of the charset > parameter. How do others feel? Do we know that all existing application/*+xml types define the charset param by reference to 3023? If so, then I agree; I believe that the benefit of this simplification outweighs the cost of (potential) redundancy. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca >From duerst@w3.org Fri Dec 19 19:55:31 2003 From: duerst at w3.org (Martin Duerst) Date: Fri Dec 19 19:55:46 2003 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <20031220000621.1347.MURATA@hokkaido.email.ne.jp> References: <4.2.0.58.J.20031218112549.00a93ad0@localhost> <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031218112549.00a93ad0@localhost> Message-ID: <4.2.0.58.J.20031219133801.06ffa768@localhost> Hello Makoto, At 00:20 03/12/20 +0900, MURATA Makoto wrote: >On Thu, 18 Dec 2003 11:30:44 -0500 >Martin Duerst wrote: > > > There is some work starting on updating RFC 3023, and we hope that > > we can use it to document the issues and questions that have > > come up on the list. Chris has volunteered to coauthor, and I'll > > help from the sidelines. Probably having all the information together > > in one place, is better than having some of the information separated out. > >As a co-author, I also agree to add some guidelines for the omission of the >charset parameter. Chris and I will start this work shortly. We are looking forward to this! >When a media type uses UTF-8 only, I can agree to omit the charset >parameter. "UTF-8" is already a recommended policy >(http://www.w3.org/TR/charmod/#sec-UniqueEncoding). I do not see strong >reasons to specify charset="utf-8" always. However, even in this case, I >am sympathetic to Martin's worry ("we start to get into a patchwork"). >In all other cases, I do not want to allow omission of the charset >parameter. How do others feel? There are two separate issues: 1) Does a registration allow the 'charset' parameter or not. 2) Does an actual entity have the 'charset' parameter or not. It is not totally clear to me which one of these you are talking above. In my opinion, it is highly preferable that all registrations allow the 'charset' parameter, to avoid a patchwork. The draft should contain some justification for this. As for whether the actual entity should come with a 'charset' parameter, we should also have a discussion of the various issues in the draft. >By the way, "The Standard Hex Format" uses UTF-8 only. > >http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt I have not found 'UTF-8' anywhere in this document, so I'm not sure where you saw this restriction. The document contains: >>>>>>>> 9.1 Optional parameters none. There is no charset parameter. Character handling has identical semantics to the case where the charset parameter of the "application/xml" media type is omitted, as described in RFC3023 [4]. >>>>>>>> I think this should be fixed to reinstate the charset parameter as discussed on this mailing list. Another one is http://www.ietf.org/internet-drafts/draft-sbml-media-type-02.txt. This was approved by the IESG yesterday, so I guess it's too late to try to change it. In practice, I very much hope that no implementation will reject sbml data that comes with a redundant charset=utf-8. Regards, Martin. >From murata@hokkaido.email.ne.jp Sat Dec 20 15:52:56 2003 From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Sat Dec 20 15:56:22 2003 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <4.2.0.58.J.20031219133801.06ffa768@localhost> References: <20031220000621.1347.MURATA@hokkaido.email.ne.jp> <4.2.0.58.J.20031219133801.06ffa768@localhost> Message-ID: <20031220230150.134C.MURATA@hokkaido.email.ne.jp> > There are two separate issues: > 1) Does a registration allow the 'charset' parameter or not. > 2) Does an actual entity have the 'charset' parameter or not. > > It is not totally clear to me which one of these you are talking above. 1) > In my opinion, it is highly preferable that all registrations > allow the 'charset' parameter, to avoid a patchwork. The draft > should contain some justification for this. RFC 3023 already provides a registration template which introduces the charset parameter. But the recommendation to introduce the charset parameter is a SHOULD rather than a MUST. People read RFC 3023 but they intentionally dropped the charset. I studied existing +xml media types registered at IANA. Here is the result. 1. IETF tree With the exception of application/cnrp+xml, all +xml media types have the charset parameter. 1) beep+xml [RFC3080] This keeps the charset parameter. 2) cnrp+xml [RFC3367] This omits the charset parameter. Not restricted to UTF-8. 3) cpl+xml [RFCXXXX] http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-08.txt This keeps the charset parameter. 4) pidf+xml [RFC-ietf-impp-cpim-pidf-08.txt] http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-08.txt This keeps the charset parameter. 5) reginfo+xml [RFC-ietf-sipping-reg-event-00.txt] http://www.ietf.org/internet-drafts/draft-ietf-sipping-reg-event-00.txt This keeps the charset parameter. 6) watcherinfo+xml [RFC-ietf-simple-winfo-format-04.txt] http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-04.txt This keeps the charset parameter. 7) xhtml+xml [RFC3236] http://www.rfc-editor.org/rfc/rfc3236.txt This keeps the charset parameter. 2. Vendor tree Only two media types have the charset parameter. Since media types in the vendor tree do not always have accompanying documents, we do not know if there are good reasons to omit the charset. 1) vnd.criticaltools.wbs+xml [Spiller] http://www.iana.org/assignments/media-types/application/vnd.criticaltools.wbs+xml This omits the charset parameter. The details of this structure are proprietary to Critical Tools, Inc. 2) vnd.irepository.package+xml [Knowles] http://www.iana.org/assignments/media-types/application/vnd.irepository.package+xml This omits the charset parameter. Use of this MIME type is limited to users of Lucidoc and associated document management tools published by iRepository.net, Inc. 3) vnd.liberty-request+xml [McDowell] http://www.iana.org/assignments/media-types/application/vnd.liberty-request+xml This omits the charset parameter. 4) vnd.llamagraphics.life-balance.exchange+xml [White] http://www.iana.org/assignments/media-types/application/vnd.llamagraphics.life-balance.exchange+xml This keeps the charset parameter. 5) vnd.mozilla.xul+xml [McDaniel] http://www.iana.org/assignments/media-types/application/vnd.mozilla.xul+xml This keeps the charset parameter. 6) vnd.pwg-xhtml-print+xml [Wright] http://www.iana.org/assignments/media-types/application/vnd.pwg-xhtml-print+xml This omits the charset parameter. 7) vnd.wv.csp+xml [Ingimundarson] http://www.iana.org/assignments/media-types/application/vnd.wv.csp+xml This omits the charset parameter. They wrote "No parameters are required - covered by client-server capability negotiation." 8) vnd.wv.csp+wbxml [Salmi] http://www.iana.org/assignments/media-types/application/vnd.wv.csp+wbxml This omits the charset parameter. They wrote "No parameters are required since WV capability negotiation covers this." 9) vnd.wv.ssp+xml [Ingimundarson] http://www.iana.org/assignments/media-types/application/vnd.wv.ssp+xml This omits the charset parameter. > As for whether the actual entity should come with a 'charset' > parameter, we should also have a discussion of the various > issues in the draft. > > > >By the way, "The Standard Hex Format" uses UTF-8 only. > > > >http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt > > I have not found 'UTF-8' anywhere in this document, so I'm not > sure where you saw this restriction. I am afraid that I made a mistake. We have discussed this issue in the mailing list, but nothing is written down yet. > Another one is > http://www.ietf.org/internet-drafts/draft-sbml-media-type-02.txt. > > This was approved by the IESG yesterday, so I guess it's too late > to try to change it. In practice, I very much hope that no implementation > will reject sbml data that comes with a redundant charset=utf-8. Now we have two exceptions in the IETF tree. Practically, what can we do? Cheers, -- MURATA Makoto From: distobj at acm.org (Mark Baker) Date: Tue Jan 3 16:22:39 2006 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <20031220000621.1347.MURATA@hokkaido.email.ne.jp>; from murata@hokkaido.email.ne.jp on Sat, Dec 20, 2003 at 12:20:01AM +0900 References: <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031218112549.00a93ad0@localhost> <20031220000621.1347.MURATA@hokkaido.email.ne.jp> Message-ID: <20031219122429.L7952@www.markbaker.ca> On Sat, Dec 20, 2003 at 12:20:01AM +0900, MURATA Makoto wrote: > However, even in this case, I > am sympathetic to Martin's worry ("we start to get into a patchwork"). > In all other cases, I do not want to allow omission of the charset > parameter. How do others feel? Do we know that all existing application/*+xml types define the charset param by reference to 3023? If so, then I agree; I believe that the benefit of this simplification outweighs the cost of (potential) redundancy. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Tue Jan 3 16:22:39 2006 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <4.2.0.58.J.20031218112549.00a93ad0@localhost> References: <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031218112549.00a93ad0@localhost> Message-ID: <20031220000621.1347.MURATA@hokkaido.email.ne.jp> On Thu, 18 Dec 2003 11:30:44 -0500 Martin Duerst wrote: > There is some work starting on updating RFC 3023, and we hope that > we can use it to document the issues and questions that have > come up on the list. Chris has volunteered to coauthor, and I'll > help from the sidelines. Probably having all the information together > in one place, is better than having some of the information separated out. As a co-author, I also agree to add some guidelines for the omission of the charset parameter. Chris and I will start this work shortly. When a media type uses UTF-8 only, I can agree to omit the charset parameter. "UTF-8" is already a recommended policy (http://www.w3.org/TR/charmod/#sec-UniqueEncoding). I do not see strong reasons to specify charset="utf-8" always. However, even in this case, I am sympathetic to Martin's worry ("we start to get into a patchwork"). In all other cases, I do not want to allow omission of the charset parameter. How do others feel? By the way, "The Standard Hex Format" uses UTF-8 only. http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt Cheers, -- MURATA Makoto From: lists at unknown.nu (Kim Scarborough) Date: Tue Jan 3 16:22:39 2006 Subject: Proposed Registration of MIME media type application/vnd.wordperfect Message-ID: <3FE22232.8080006@unknown.nu> MIME media type name: application MIME subtype name: vnd.wordperfect Required parameters: none Optional parameters: none Encoding Considerations: Wordperfect files are binary data and should be suitably encoded for protocols that do not handle binary data. Security Considerations: The security issues associated with this type have not been assessed. Interoperability considerations: As this is not an open standard, interoperability is left up to the discretion of the developer (currently Corel Corp.). Published specification: none Applications which use this media type: The WordPerfect suite of office applications. Additional information: Magic number(s): none File extension: .wpd Macintosh File Type Code(s): "WPC2" Person & email address to contact for further information: Questions about this proposal should be directed to Kim Scarborough . Intended usage: COMMON Author/Change controller: Corel Corporation 1600 Carling Avenue Ottawa, Ontario Canada K1Z 8R7 From: duerst at w3.org (Martin Duerst) Date: Thu Dec 18 21:56:57 2003 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <878yladmbb.fsf@w3.org> References: <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost> <1071764448.22957.11.camel@felicia> Message-ID: <4.2.0.58.J.20031218132824.07129d38@localhost> At 19:15 03/12/18 +0100, Max Froumentin wrote: >Linus Walleij wrote: > > OK so then I regard this as official W3.org policy on transport type. > >I expect that that policy would rather be set by the TAG. See: >http://www.w3.org/2001/tag/2002/0129-mime > >"Thus there is no ambiguity when the charset is omitted, and the >STRONGLY RECOMMENDED injunction [in RFC3023] to use the charset is >misplaced for application/xml and for non-text "+xml" >types. I agree that we should change the 'strongly recommended' to a more balanced wording and a more detailed discussion in the upcomming RFC 3023 update. I also just found out that there are apparently two findings dealing with the above issue, the other one (still at draft stage) at http://www.w3.org/2001/tag/doc/mime-respect-20031210.html (diff at http://www.w3.org/2001/tag/doc/mime-respect-20031210-diff.html). >Consequently, for XML representations, server-side applications >SHOULD only supply a charset header when there is complete certainty >as to the encoding in use. Otherwise, an error will cause a perfectly >usable representation to be rejected by an architecturally sound >client." I think that this is basically right, but highly overstated. There are two points: 1) It implies that leaving off the charset parameter will always lead to perfectly correct documents. While there are certain cases where indeed leaving out the charset parameter will improve things, when the charset parameter is wrong, there are also cases where things will get worse, and there are cases where things are not affected. 2) The language used seems to be inappropriate for a specification, because specifications in general assume that people do what the spec says. If we would fill up our specs with notes saying that you shouldn't do this if you don't get it right, our specs would all be much longer and much more difficult to read. In addition, note that the finding you cited continues as follows: >>>>>>>> We recommend that section 7.1 of [RFC3023] be amended to something like the following: The use of the charset parameter, when the charset is reliably known and agrees with the encoding declaration, is RECOMMENDED, since this information can be used by non-XML processors to determine authoritatively the charset of the XML MIME entity. >>>>>>>> So it does not look to me that the TAG is recommending to remove the charset parameter from application/foo+xml registrations. Regards, Martin. >From lists@unknown.nu Thu Dec 18 22:54:58 2003 From: lists at unknown.nu (Kim Scarborough) Date: Thu Dec 18 22:55:03 2003 Subject: Proposed Registration of MIME media type application/vnd.wordperfect Message-ID: <3FE22232.8080006@unknown.nu> MIME media type name: application MIME subtype name: vnd.wordperfect Required parameters: none Optional parameters: none Encoding Considerations: Wordperfect files are binary data and should be suitably encoded for protocols that do not handle binary data. Security Considerations: The security issues associated with this type have not been assessed. Interoperability considerations: As this is not an open standard, interoperability is left up to the discretion of the developer (currently Corel Corp.). Published specification: none Applications which use this media type: The WordPerfect suite of office applications. Additional information: Magic number(s): none File extension: .wpd Macintosh File Type Code(s): "WPC2" Person & email address to contact for further information: Questions about this proposal should be directed to Kim Scarborough . Intended usage: COMMON Author/Change controller: Corel Corporation 1600 Carling Avenue Ottawa, Ontario Canada K1Z 8R7 >From murata@hokkaido.email.ne.jp Fri Dec 19 16:20:01 2003 From: murata at hokkaido.email.ne.jp (MURATA Makoto) Date: Fri Dec 19 16:23:27 2003 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <4.2.0.58.J.20031218112549.00a93ad0@localhost> References: <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031218112549.00a93ad0@localhost> Message-ID: <20031220000621.1347.MURATA@hokkaido.email.ne.jp> On Thu, 18 Dec 2003 11:30:44 -0500 Martin Duerst wrote: > There is some work starting on updating RFC 3023, and we hope that > we can use it to document the issues and questions that have > come up on the list. Chris has volunteered to coauthor, and I'll > help from the sidelines. Probably having all the information together > in one place, is better than having some of the information separated out. As a co-author, I also agree to add some guidelines for the omission of the charset parameter. Chris and I will start this work shortly. When a media type uses UTF-8 only, I can agree to omit the charset parameter. "UTF-8" is already a recommended policy (http://www.w3.org/TR/charmod/#sec-UniqueEncoding). I do not see strong reasons to specify charset="utf-8" always. However, even in this case, I am sympathetic to Martin's worry ("we start to get into a patchwork"). In all other cases, I do not want to allow omission of the charset parameter. How do others feel? By the way, "The Standard Hex Format" uses UTF-8 only. http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt Cheers, -- MURATA Makoto From: duerst at w3.org (Martin Duerst) Date: Tue Jan 3 16:22:39 2006 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <878yladmbb.fsf@w3.org> References: <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost> <1071764448.22957.11.camel@felicia> Message-ID: <4.2.0.58.J.20031218132824.07129d38@localhost> At 19:15 03/12/18 +0100, Max Froumentin wrote: >Linus Walleij wrote: > > OK so then I regard this as official W3.org policy on transport type. > >I expect that that policy would rather be set by the TAG. See: >http://www.w3.org/2001/tag/2002/0129-mime > >"Thus there is no ambiguity when the charset is omitted, and the >STRONGLY RECOMMENDED injunction [in RFC3023] to use the charset is >misplaced for application/xml and for non-text "+xml" >types. I agree that we should change the 'strongly recommended' to a more balanced wording and a more detailed discussion in the upcomming RFC 3023 update. I also just found out that there are apparently two findings dealing with the above issue, the other one (still at draft stage) at http://www.w3.org/2001/tag/doc/mime-respect-20031210.html (diff at http://www.w3.org/2001/tag/doc/mime-respect-20031210-diff.html). >Consequently, for XML representations, server-side applications >SHOULD only supply a charset header when there is complete certainty >as to the encoding in use. Otherwise, an error will cause a perfectly >usable representation to be rejected by an architecturally sound >client." I think that this is basically right, but highly overstated. There are two points: 1) It implies that leaving off the charset parameter will always lead to perfectly correct documents. While there are certain cases where indeed leaving out the charset parameter will improve things, when the charset parameter is wrong, there are also cases where things will get worse, and there are cases where things are not affected. 2) The language used seems to be inappropriate for a specification, because specifications in general assume that people do what the spec says. If we would fill up our specs with notes saying that you shouldn't do this if you don't get it right, our specs would all be much longer and much more difficult to read. In addition, note that the finding you cited continues as follows: >>>>>>>> We recommend that section 7.1 of [RFC3023] be amended to something like the following: The use of the charset parameter, when the charset is reliably known and agrees with the encoding declaration, is RECOMMENDED, since this information can be used by non-XML processors to determine authoritatively the charset of the XML MIME entity. >>>>>>>> So it does not look to me that the TAG is recommending to remove the charset parameter from application/foo+xml registrations. Regards, Martin. From: mf at w3.org (Max Froumentin) Date: Tue Jan 3 16:22:39 2006 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <1071764448.22957.11.camel@felicia> (Linus Walleij's message of "Thu, 18 Dec 2003 17:20:51 +0100") References: <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost> <1071764448.22957.11.camel@felicia> Message-ID: <878yladmbb.fsf@w3.org> Linus Walleij wrote: > ons 2003-12-17 klockan 00.12 skrev Martin Duerst: >> Sorry I forgot to mention it, but Chris and me actually had such a >> 'meeting' last week, and the email I wrote was the result of this >> (and a phone call with Max). > > OK so then I regard this as official W3.org policy on transport type. I expect that that policy would rather be set by the TAG. See: http://www.w3.org/2001/tag/2002/0129-mime "Thus there is no ambiguity when the charset is omitted, and the STRONGLY RECOMMENDED injunction [in RFC3023] to use the charset is misplaced for application/xml and for non-text "+xml" types. Consequently, for XML representations, server-side applications SHOULD only supply a charset header when there is complete certainty as to the encoding in use. Otherwise, an error will cause a perfectly usable representation to be rejected by an architecturally sound client." I don't know what Martin or Chris would have to say to that. Max. From: duerst at w3.org (Martin Duerst) Date: Thu Dec 18 17:44:25 2003 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <1071764448.22957.11.camel@felicia> References: <4.2.0.58.J.20031216180134.06e36e20@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost> Message-ID: <4.2.0.58.J.20031218112549.00a93ad0@localhost> At 17:20 03/12/18 +0100, Linus Walleij wrote: >ons 2003-12-17 klockan 00.12 skrev Martin Duerst: > > > Sorry I forgot to mention it, but Chris and me actually had such a > > 'meeting' last week, and the email I wrote was the result of this > > (and a phone call with Max). > >OK so then I regard this as official W3.org policy on transport type. You can regard it as what you want. As far as I understand, it represents our best knowledge. But it is in no way 'official' as far as W3C is concerned. >If you three (Martin, Chris and Max) could write up an informational >RFC on how you believe foo/bar+xml transport types should be handled >we could sort out this issue once and for all. I think noone would >object to a transport type policy for XML from three W3.org members. There is some work starting on updating RFC 3023, and we hope that we can use it to document the issues and questions that have come up on the list. Chris has volunteered to coauthor, and I'll help from the sidelines. Probably having all the information together in one place, is better than having some of the information separated out. Regards, Martin. >From mf@w3.org Thu Dec 18 19:15:36 2003 From: mf at w3.org (Max Froumentin) Date: Thu Dec 18 19:17:22 2003 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <1071764448.22957.11.camel@felicia> (Linus Walleij's message of "Thu, 18 Dec 2003 17:20:51 +0100") References: <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost> <1071764448.22957.11.camel@felicia> Message-ID: <878yladmbb.fsf@w3.org> Linus Walleij wrote: > ons 2003-12-17 klockan 00.12 skrev Martin Duerst: >> Sorry I forgot to mention it, but Chris and me actually had such a >> 'meeting' last week, and the email I wrote was the result of this >> (and a phone call with Max). > > OK so then I regard this as official W3.org policy on transport type. I expect that that policy would rather be set by the TAG. See: http://www.w3.org/2001/tag/2002/0129-mime "Thus there is no ambiguity when the charset is omitted, and the STRONGLY RECOMMENDED injunction [in RFC3023] to use the charset is misplaced for application/xml and for non-text "+xml" types. Consequently, for XML representations, server-side applications SHOULD only supply a charset header when there is complete certainty as to the encoding in use. Otherwise, an error will cause a perfectly usable representation to be rejected by an architecturally sound client." I don't know what Martin or Chris would have to say to that. Max. From: duerst at w3.org (Martin Duerst) Date: Tue Jan 3 16:22:39 2006 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <1071764448.22957.11.camel@felicia> References: <4.2.0.58.J.20031216180134.06e36e20@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost> Message-ID: <4.2.0.58.J.20031218112549.00a93ad0@localhost> At 17:20 03/12/18 +0100, Linus Walleij wrote: >ons 2003-12-17 klockan 00.12 skrev Martin Duerst: > > > Sorry I forgot to mention it, but Chris and me actually had such a > > 'meeting' last week, and the email I wrote was the result of this > > (and a phone call with Max). > >OK so then I regard this as official W3.org policy on transport type. You can regard it as what you want. As far as I understand, it represents our best knowledge. But it is in no way 'official' as far as W3C is concerned. >If you three (Martin, Chris and Max) could write up an informational >RFC on how you believe foo/bar+xml transport types should be handled >we could sort out this issue once and for all. I think noone would >object to a transport type policy for XML from three W3.org members. There is some work starting on updating RFC 3023, and we hope that we can use it to document the issues and questions that have come up on the list. Chris has volunteered to coauthor, and I'll help from the sidelines. Probably having all the information together in one place, is better than having some of the information separated out. Regards, Martin. From: triad at df.lth.se (Linus Walleij) Date: Tue Jan 3 16:22:39 2006 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <4.2.0.58.J.20031216180134.06e36e20@localhost> References: <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost> Message-ID: <1071764448.22957.11.camel@felicia> ons 2003-12-17 klockan 00.12 skrev Martin Duerst: > Sorry I forgot to mention it, but Chris and me actually had such a > 'meeting' last week, and the email I wrote was the result of this > (and a phone call with Max). OK so then I regard this as official W3.org policy on transport type. If you three (Martin, Chris and Max) could write up an informational RFC on how you believe foo/bar+xml transport types should be handled we could sort out this issue once and for all. I think noone would object to a transport type policy for XML from three W3.org members. What do you say? -- Linus Walleij From: moore at cs.utk.edu (Keith Moore) Date: Wed Dec 17 22:59:13 2003 Subject: please review 'application/pdf' -- new version In-Reply-To: <000001c3c4d5$a4c68e60$bf422099@MasinterT40> References: <20031217133152.20a0144e.moore@cs.utk.edu> <000001c3c4d5$a4c68e60$bf422099@MasinterT40> Message-ID: <20031217165906.72576d69.moore@cs.utk.edu> that strikes me as a reasonable way to handle the issue of what kinds of control Adobe believes it can assert over use of PDF. OTOH, If the resulting draft still had statements to the effect that implementations "must" implement the permissions stuff, I'd consider that a separate issue. Keith > > The disclaimer notwithstanding, it still creates the > > appearance of IETF support. > > In rereviewing IETF practices in this area, I think the right > thing to do is to remove the IPR claims from the internet > draft. A separate IPR notice can be sent to statements@ietf.org. > The internet draft (and the subsequent RFC) would then contain > the standard notice that there are IPR claims related to > the technology in the draft. > > I think this will address the issue of having an RFC > seem to endorse the legitimacy IPR claims, despite the > appearance of a disclaimer. > > Larry > > >From triad@df.lth.se Thu Dec 18 17:20:51 2003 From: triad at df.lth.se (Linus Walleij) Date: Thu Dec 18 17:21:05 2003 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <4.2.0.58.J.20031216180134.06e36e20@localhost> References: <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost> Message-ID: <1071764448.22957.11.camel@felicia> ons 2003-12-17 klockan 00.12 skrev Martin Duerst: > Sorry I forgot to mention it, but Chris and me actually had such a > 'meeting' last week, and the email I wrote was the result of this > (and a phone call with Max). OK so then I regard this as official W3.org policy on transport type. If you three (Martin, Chris and Max) could write up an informational RFC on how you believe foo/bar+xml transport types should be handled we could sort out this issue once and for all. I think noone would object to a transport type policy for XML from three W3.org members. What do you say? -- Linus Walleij From: moore at cs.utk.edu (Keith Moore) Date: Tue Jan 3 16:22:39 2006 Subject: please review 'application/pdf' -- new version In-Reply-To: <000001c3c4d5$a4c68e60$bf422099@MasinterT40> References: <20031217133152.20a0144e.moore@cs.utk.edu> <000001c3c4d5$a4c68e60$bf422099@MasinterT40> Message-ID: <20031217165906.72576d69.moore@cs.utk.edu> that strikes me as a reasonable way to handle the issue of what kinds of control Adobe believes it can assert over use of PDF. OTOH, If the resulting draft still had statements to the effect that implementations "must" implement the permissions stuff, I'd consider that a separate issue. Keith > > The disclaimer notwithstanding, it still creates the > > appearance of IETF support. > > In rereviewing IETF practices in this area, I think the right > thing to do is to remove the IPR claims from the internet > draft. A separate IPR notice can be sent to statements@ietf.org. > The internet draft (and the subsequent RFC) would then contain > the standard notice that there are IPR claims related to > the technology in the draft. > > I think this will address the issue of having an RFC > seem to endorse the legitimacy IPR claims, despite the > appearance of a disclaimer. > > Larry > > From: duerst at w3.org (Martin Duerst) Date: Wed Dec 17 21:44:29 2003 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <20031217181719.GA11430@mauzo.mauzo.dyndns.org> References: <4.2.0.58.J.20031216160942.077942a8@localhost> <87ptewu3gc.fsf@w3.org> <4.2.0.58.J.20031216160942.077942a8@localhost> Message-ID: <4.2.0.58.J.20031217152847.077c2078@localhost> Hello Ben, [Putting ietf-xml-mime@imc.org back on the cc list, because I think quite some of this discussion may make its way into the next version of RFC 3023 in one way or another.] At 18:17 03/12/17 +0000, ben@morrow.me.uk wrote: >At 4pm on 16/12/03 Martin Duerst wrote: > > I just by chance realized that you had removed the 'charset' > > parameter from the registration for application/voicexml+xml, > > and also for application/ssml+xml. I have found something similar > > in other recent registration proposals. >The usual intent when omitting the 'charset' parameter from the >registration is that the XML *must* be encoded in UTF8 or UTF16. This is an interesting idea. Can you point to any actual registrations where this is the case? >If this is done, then the entity will not need to include a charset >declaration in the body either, and will be universally understood >everywhere. Yes, this is true for application/foo+xml. For text/foo+xml, it is not true, but then I hope nobody is talking about that anyway. >I would suggest that those registrations which do not >specify a charset be updated to state that encodings other than UTF8 >and UTF16 may not be used. I'm not really sure that this helps. It would not work together with any of the points I have brought up: - Generic xml processors would still accept 'charset' parameters, even if the registration forbade it. They also would still accept content in other encodings (with quite some variation, of course), whether declared with a 'charset' parameter or with the encoding pseudo-attribute on an XML declaration. - Technology such as JSP and databases would still produce 'charset' parameters, even if the registration didn't allow it. There may be cases where one wants a certain media type to be restricted to UTF-8 and UTF-16 (or even in some cases only one of them), but just saying "no charset parameter on media type == UTF-8 or UTF-16 only" doesn't really cut it. Regards, Martin. From: duerst at w3.org (Martin Duerst) Date: Tue Jan 3 16:22:39 2006 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <20031217181719.GA11430@mauzo.mauzo.dyndns.org> References: <4.2.0.58.J.20031216160942.077942a8@localhost> <87ptewu3gc.fsf@w3.org> <4.2.0.58.J.20031216160942.077942a8@localhost> Message-ID: <4.2.0.58.J.20031217152847.077c2078@localhost> Hello Ben, [Putting ietf-xml-mime@imc.org back on the cc list, because I think quite some of this discussion may make its way into the next version of RFC 3023 in one way or another.] At 18:17 03/12/17 +0000, ben@morrow.me.uk wrote: >At 4pm on 16/12/03 Martin Duerst wrote: > > I just by chance realized that you had removed the 'charset' > > parameter from the registration for application/voicexml+xml, > > and also for application/ssml+xml. I have found something similar > > in other recent registration proposals. >The usual intent when omitting the 'charset' parameter from the >registration is that the XML *must* be encoded in UTF8 or UTF16. This is an interesting idea. Can you point to any actual registrations where this is the case? >If this is done, then the entity will not need to include a charset >declaration in the body either, and will be universally understood >everywhere. Yes, this is true for application/foo+xml. For text/foo+xml, it is not true, but then I hope nobody is talking about that anyway. >I would suggest that those registrations which do not >specify a charset be updated to state that encodings other than UTF8 >and UTF16 may not be used. I'm not really sure that this helps. It would not work together with any of the points I have brought up: - Generic xml processors would still accept 'charset' parameters, even if the registration forbade it. They also would still accept content in other encodings (with quite some variation, of course), whether declared with a 'charset' parameter or with the encoding pseudo-attribute on an XML declaration. - Technology such as JSP and databases would still produce 'charset' parameters, even if the registration didn't allow it. There may be cases where one wants a certain media type to be restricted to UTF-8 and UTF-16 (or even in some cases only one of them), but just saying "no charset parameter on media type == UTF-8 or UTF-16 only" doesn't really cut it. Regards, Martin. From: LMM at acm.org (Larry Masinter) Date: Wed Dec 17 20:40:59 2003 Subject: please review 'application/pdf' -- new version In-Reply-To: <20031217133152.20a0144e.moore@cs.utk.edu> Message-ID: <000001c3c4d5$a4c68e60$bf422099@MasinterT40> > The disclaimer notwithstanding, it still creates the > appearance of IETF support. In rereviewing IETF practices in this area, I think the right thing to do is to remove the IPR claims from the internet draft. A separate IPR notice can be sent to statements@ietf.org. The internet draft (and the subsequent RFC) would then contain the standard notice that there are IPR claims related to the technology in the draft. I think this will address the issue of having an RFC seem to endorse the legitimacy IPR claims, despite the appearance of a disclaimer. Larry From: LMM at acm.org (Larry Masinter) Date: Tue Jan 3 16:22:39 2006 Subject: please review 'application/pdf' -- new version In-Reply-To: <20031217133152.20a0144e.moore@cs.utk.edu> Message-ID: <000001c3c4d5$a4c68e60$bf422099@MasinterT40> > The disclaimer notwithstanding, it still creates the > appearance of IETF support. In rereviewing IETF practices in this area, I think the right thing to do is to remove the IPR claims from the internet draft. A separate IPR notice can be sent to statements@ietf.org. The internet draft (and the subsequent RFC) would then contain the standard notice that there are IPR claims related to the technology in the draft. I think this will address the issue of having an RFC seem to endorse the legitimacy IPR claims, despite the appearance of a disclaimer. Larry From: moore at cs.utk.edu (Keith Moore) Date: Tue Jan 3 16:22:39 2006 Subject: please review 'application/pdf' -- new version In-Reply-To: <003b01c3c4c6$5e039e50$6701a8c0@MasinterT40> References: <003b01c3c4c6$5e039e50$6701a8c0@MasinterT40> Message-ID: <20031217133152.20a0144e.moore@cs.utk.edu> > > > that's certainly better than the original text. however, I still > > don't want IETF endorsing Adobe's insistence that PDF permissions > > inherently reflect the content-owner's intent, nor that viewer > > authors "must" take away legitimate rights from those who are > > reading the documents -which are not completely the content-owner's > > to control. > > > > would you folks please stop trying to screw the public? > > Keith, > > It's a little hard to work through your conspiracy-theory > approach to the topic. Certainly I can assure you that > there is no intent to "try to screw the public". PDF's DRM is very much an attempt to screw the public, since it attempts to take away rights that the public has and transfer them to the person who packages the document in PDF format. That may not be precisely the intent, but it's the effect. Calling it a name (like "conspriacy theory") doesn't change the fact. > I'm not sure what in the document would need to change. I'll try to suggest specific text. > Certainly a protocol that contains an ACL represents the > intent of the sender of the ACL about the access to the > data that is intended to be controlled by that ACL. Well, any protocol that trusts the recipient of a document to honor an ACL is in a pretty dubious security position anyway. But I don't see a problem with saying that this is what PDF permissions "mean". I do see a problem with saying that implementations "must" honor those permissions. > In any case, the IETF, when publishing an informational document, does > not "endorse" the document or any IPR rights claimed in it -- The disclaimer notwithstanding, it still creates the appearance of IETF support. This would hardly be the first time that a vendor has tried to get the appearance of legitimacy for a harmful practice by publishing it as an RFC. From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Wed Dec 17 19:18:32 2003 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <4.2.0.58.J.20031216160942.077942a8@localhost> References: <87ptewu3gc.fsf@w3.org> <4.2.0.58.J.20031216160942.077942a8@localhost> Message-ID: <20031217181719.GA11430@mauzo.mauzo.dyndns.org> At 4pm on 16/12/03 Martin Duerst wrote: > I just by chance realized that you had removed the 'charset' > parameter from the registration for application/voicexml+xml, > and also for application/ssml+xml. I have found something similar > in other recent registration proposals. > > Here is why I think this is really not a good idea: > > First, we start to get into a patchwork where some types > allow the 'charset', and others don't. Assuming that there > is something like generic XML processors (e.g. parsers) > (which is the whole point of XML), how should such a parser > know whether the 'charset' parameter is allowed or not, > and keep up with new registrations? > > Second, there are various scenarios a charset parameter in > the header is automatically generated, or where it's much > easier to generate it than to avoid it. > Again, if they use generic technology, > getting the 'charset' into the header is much more straightforward > than putting it into the body. The usual intent when omitting the 'charset' parameter from the registration is that the XML *must* be encoded in UTF8 or UTF16. If this is done, then the entity will not need to include a charset declaration in the body either, and will be universally understood everywhere. I would suggest that those registrations which do not specify a charset be updated to state that encodings other than UTF8 and UTF16 may not be used. Ben >From moore@cs.utk.edu Wed Dec 17 19:31:52 2003 From: moore at cs.utk.edu (Keith Moore) Date: Wed Dec 17 19:31:57 2003 Subject: please review 'application/pdf' -- new version In-Reply-To: <003b01c3c4c6$5e039e50$6701a8c0@MasinterT40> References: <003b01c3c4c6$5e039e50$6701a8c0@MasinterT40> Message-ID: <20031217133152.20a0144e.moore@cs.utk.edu> > > > that's certainly better than the original text. however, I still > > don't want IETF endorsing Adobe's insistence that PDF permissions > > inherently reflect the content-owner's intent, nor that viewer > > authors "must" take away legitimate rights from those who are > > reading the documents -which are not completely the content-owner's > > to control. > > > > would you folks please stop trying to screw the public? > > Keith, > > It's a little hard to work through your conspiracy-theory > approach to the topic. Certainly I can assure you that > there is no intent to "try to screw the public". PDF's DRM is very much an attempt to screw the public, since it attempts to take away rights that the public has and transfer them to the person who packages the document in PDF format. That may not be precisely the intent, but it's the effect. Calling it a name (like "conspriacy theory") doesn't change the fact. > I'm not sure what in the document would need to change. I'll try to suggest specific text. > Certainly a protocol that contains an ACL represents the > intent of the sender of the ACL about the access to the > data that is intended to be controlled by that ACL. Well, any protocol that trusts the recipient of a document to honor an ACL is in a pretty dubious security position anyway. But I don't see a problem with saying that this is what PDF permissions "mean". I do see a problem with saying that implementations "must" honor those permissions. > In any case, the IETF, when publishing an informational document, does > not "endorse" the document or any IPR rights claimed in it -- The disclaimer notwithstanding, it still creates the appearance of IETF support. This would hardly be the first time that a vendor has tried to get the appearance of legitimacy for a harmful practice by publishing it as an RFC. From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Tue Jan 3 16:22:39 2006 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <4.2.0.58.J.20031216160942.077942a8@localhost> References: <87ptewu3gc.fsf@w3.org> <4.2.0.58.J.20031216160942.077942a8@localhost> Message-ID: <20031217181719.GA11430@mauzo.mauzo.dyndns.org> At 4pm on 16/12/03 Martin Duerst wrote: > I just by chance realized that you had removed the 'charset' > parameter from the registration for application/voicexml+xml, > and also for application/ssml+xml. I have found something similar > in other recent registration proposals. > > Here is why I think this is really not a good idea: > > First, we start to get into a patchwork where some types > allow the 'charset', and others don't. Assuming that there > is something like generic XML processors (e.g. parsers) > (which is the whole point of XML), how should such a parser > know whether the 'charset' parameter is allowed or not, > and keep up with new registrations? > > Second, there are various scenarios a charset parameter in > the header is automatically generated, or where it's much > easier to generate it than to avoid it. > Again, if they use generic technology, > getting the 'charset' into the header is much more straightforward > than putting it into the body. The usual intent when omitting the 'charset' parameter from the registration is that the XML *must* be encoded in UTF8 or UTF16. If this is done, then the entity will not need to include a charset declaration in the body either, and will be universally understood everywhere. I would suggest that those registrations which do not specify a charset be updated to state that encodings other than UTF8 and UTF16 may not be used. Ben From: LMM at acm.org (Larry Masinter) Date: Wed Dec 17 18:51:36 2003 Subject: please review 'application/pdf' -- new version In-Reply-To: Message-ID: <003b01c3c4c6$5e039e50$6701a8c0@MasinterT40> > that's certainly better than the original text. however, I still don't > want IETF endorsing Adobe's insistence that PDF permissions inherently > reflect the content-owner's intent, nor that viewer authors "must" take > away legitimate rights from those who are reading the documents - which > are not completely the content-owner's to control. > > would you folks please stop trying to screw the public? Keith, It's a little hard to work through your conspiracy-theory approach to the topic. Certainly I can assure you that there is no intent to "try to screw the public". I'm not sure what in the document would need to change. Certainly a protocol that contains an ACL represents the intent of the sender of the ACL about the access to the data that is intended to be controlled by that ACL. In any case, the IETF, when publishing an informational document, does not "endorse" the document or any IPR rights claimed in it -- in fact, there's a specific disclaimer included: The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.... Would you like a specific reference to that disclaimer in the body of the document? Larry From: LMM at acm.org (Larry Masinter) Date: Tue Jan 3 16:22:39 2006 Subject: please review 'application/pdf' -- new version In-Reply-To: Message-ID: <003b01c3c4c6$5e039e50$6701a8c0@MasinterT40> > that's certainly better than the original text. however, I still don't > want IETF endorsing Adobe's insistence that PDF permissions inherently > reflect the content-owner's intent, nor that viewer authors "must" take > away legitimate rights from those who are reading the documents - which > are not completely the content-owner's to control. > > would you folks please stop trying to screw the public? Keith, It's a little hard to work through your conspiracy-theory approach to the topic. Certainly I can assure you that there is no intent to "try to screw the public". I'm not sure what in the document would need to change. Certainly a protocol that contains an ACL represents the intent of the sender of the ACL about the access to the data that is intended to be controlled by that ACL. In any case, the IETF, when publishing an informational document, does not "endorse" the document or any IPR rights claimed in it -- in fact, there's a specific disclaimer included: The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.... Would you like a specific reference to that disclaimer in the body of the document? Larry From: moore at cs.utk.edu (Keith Moore) Date: Wed Dec 17 14:49:44 2003 Subject: please review 'application/pdf' -- new version In-Reply-To: <001a01c3c469$2e7f4a10$6701a8c0@MasinterT40> References: <001a01c3c469$2e7f4a10$6701a8c0@MasinterT40> Message-ID: > With regard to Keith's objections about the claims about > the "document author's copyright", I'm happy to note that > Adobe has published an errata at > > http://partners.adobe.com/asn/acrobat/sdk/public/docs/errata.txt > > which removes the sentence which caused the original complaint; > the copyright claims in the internet draft were updated to match. that's certainly better than the original text. however, I still don't want IETF endorsing Adobe's insistence that PDF permissions inherently reflect the content-owner's intent, nor that viewer authors "must" take away legitimate rights from those who are reading the documents - which are not completely the content-owner's to control. would you folks please stop trying to screw the public? From: moore at cs.utk.edu (Keith Moore) Date: Tue Jan 3 16:22:39 2006 Subject: please review 'application/pdf' -- new version In-Reply-To: <001a01c3c469$2e7f4a10$6701a8c0@MasinterT40> References: <001a01c3c469$2e7f4a10$6701a8c0@MasinterT40> Message-ID: > With regard to Keith's objections about the claims about > the "document author's copyright", I'm happy to note that > Adobe has published an errata at > > http://partners.adobe.com/asn/acrobat/sdk/public/docs/errata.txt > > which removes the sentence which caused the original complaint; > the copyright claims in the internet draft were updated to match. that's certainly better than the original text. however, I still don't want IETF endorsing Adobe's insistence that PDF permissions inherently reflect the content-owner's intent, nor that viewer authors "must" take away legitimate rights from those who are reading the documents - which are not completely the content-owner's to control. would you folks please stop trying to screw the public? From: LMM at acm.org (Larry Masinter) Date: Tue Jan 3 16:22:39 2006 Subject: please review 'application/pdf' -- new version In-Reply-To: <11DFD398-2945-11D8-97F7-000393DB5366@cs.utk.edu> Message-ID: <001a01c3c469$2e7f4a10$6701a8c0@MasinterT40> We have just posted draft-zilles-pdf-01.txt to internet-drafts, so it should appear in a day or two. In the meanwhile, I also posted a copy to http://larry.masinter.net/draft-zilles-pdf-01.txt There were a number of private comments which caused updates to several sections (the intro, fragment identifiers section, and a better description of digital signatures, fixed up references.) If anyone wants diffs, I'll be happy to send them to you. With regard to Keith's objections about the claims about the "document author's copyright", I'm happy to note that Adobe has published an errata at http://partners.adobe.com/asn/acrobat/sdk/public/docs/errata.txt which removes the sentence which caused the original complaint; the copyright claims in the internet draft were updated to match. I believe this draft now addresses all the issues that were raised. > If Adobe wants to point out that there is such a thing as access > permissions in PDF, that's merely providing information which > might be useful to the reader. Exactly; I believe it meets the criteria for Informational status. Larry From: duerst at w3.org (Martin Duerst) Date: Wed Dec 17 00:19:17 2003 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <1071614605.15819.19.camel@felicia> References: <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> Message-ID: <4.2.0.58.J.20031216180134.06e36e20@localhost> Hello Linus, At 23:43 03/12/16 +0100, Linus Walleij wrote: >tis 2003-12-16 klockan 22.32 skrev Martin Duerst: > > > I just by chance realized that you had removed the 'charset' > > parameter from the registration for application/voicexml+xml, > > and also for application/ssml+xml. I have found something similar > > in other recent registration proposals. > >Now, wait a second here. > >Now there is Martin Duerst from W3.org telling us that we must >indeed include a "charset" parameter with our foo/bar+xml >MIME transport types. > >Then there is Chris Lilley of the same W3.org telling us *repeatedly* >to remove it: First, we are on an IETF list, which means that we are all acting as concerned individuals, and that we are mainly interested in getting the best possible solution. >Now, I've been trusting Chris up til now, simply because he >represents W3.org. > >You are of course welcome to run your internal disputes on the >issue on these lists if you like, but when you're already at the >same organizational body, could you *PLEASE* book an internal meeting >and try to formulate a consensus from the W3.org side on how you >think this thing should be handled? After all, you invented XML. Sorry I forgot to mention it, but Chris and me actually had such a 'meeting' last week, and the email I wrote was the result of this (and a phone call with Max). Regards, Martin. >From LMM@acm.org Wed Dec 17 07:44:12 2003 From: LMM at acm.org (Larry Masinter) Date: Wed Dec 17 07:45:08 2003 Subject: please review 'application/pdf' -- new version In-Reply-To: <11DFD398-2945-11D8-97F7-000393DB5366@cs.utk.edu> Message-ID: <001a01c3c469$2e7f4a10$6701a8c0@MasinterT40> We have just posted draft-zilles-pdf-01.txt to internet-drafts, so it should appear in a day or two. In the meanwhile, I also posted a copy to http://larry.masinter.net/draft-zilles-pdf-01.txt There were a number of private comments which caused updates to several sections (the intro, fragment identifiers section, and a better description of digital signatures, fixed up references.) If anyone wants diffs, I'll be happy to send them to you. With regard to Keith's objections about the claims about the "document author's copyright", I'm happy to note that Adobe has published an errata at http://partners.adobe.com/asn/acrobat/sdk/public/docs/errata.txt which removes the sentence which caused the original complaint; the copyright claims in the internet draft were updated to match. I believe this draft now addresses all the issues that were raised. > If Adobe wants to point out that there is such a thing as access > permissions in PDF, that's merely providing information which > might be useful to the reader. Exactly; I believe it meets the criteria for Informational status. Larry From: duerst at w3.org (Martin Duerst) Date: Tue Jan 3 16:22:39 2006 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <1071614605.15819.19.camel@felicia> References: <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> Message-ID: <4.2.0.58.J.20031216180134.06e36e20@localhost> Hello Linus, At 23:43 03/12/16 +0100, Linus Walleij wrote: >tis 2003-12-16 klockan 22.32 skrev Martin Duerst: > > > I just by chance realized that you had removed the 'charset' > > parameter from the registration for application/voicexml+xml, > > and also for application/ssml+xml. I have found something similar > > in other recent registration proposals. > >Now, wait a second here. > >Now there is Martin Duerst from W3.org telling us that we must >indeed include a "charset" parameter with our foo/bar+xml >MIME transport types. > >Then there is Chris Lilley of the same W3.org telling us *repeatedly* >to remove it: First, we are on an IETF list, which means that we are all acting as concerned individuals, and that we are mainly interested in getting the best possible solution. >Now, I've been trusting Chris up til now, simply because he >represents W3.org. > >You are of course welcome to run your internal disputes on the >issue on these lists if you like, but when you're already at the >same organizational body, could you *PLEASE* book an internal meeting >and try to formulate a consensus from the W3.org side on how you >think this thing should be handled? After all, you invented XML. Sorry I forgot to mention it, but Chris and me actually had such a 'meeting' last week, and the email I wrote was the result of this (and a phone call with Max). Regards, Martin. From: triad at df.lth.se (Linus Walleij) Date: Tue Dec 16 23:43:38 2003 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <4.2.0.58.J.20031216160942.077942a8@localhost> References: <4.2.0.58.J.20031216160942.077942a8@localhost> Message-ID: <1071614605.15819.19.camel@felicia> tis 2003-12-16 klockan 22.32 skrev Martin Duerst: > I just by chance realized that you had removed the 'charset' > parameter from the registration for application/voicexml+xml, > and also for application/ssml+xml. I have found something similar > in other recent registration proposals. Now, wait a second here. Now there is Martin Duerst from W3.org telling us that we must indeed include a "charset" parameter with our foo/bar+xml MIME transport types. Then there is Chris Lilley of the same W3.org telling us *repeatedly* to remove it: > I suggest removing this optional parameter as follows: > > There is no charset parameter. Character handling has identical > semantics to the case where the charset parameter of the > "application/xml" media type is omitted, as described in > [RFC3023]. Now, I've been trusting Chris up til now, simply because he represents W3.org. You are of course welcome to run your internal disputes on the issue on these lists if you like, but when you're already at the same organizational body, could you *PLEASE* book an internal meeting and try to formulate a consensus from the W3.org side on how you think this thing should be handled? After all, you invented XML. Linus Walleij From: triad at df.lth.se (Linus Walleij) Date: Tue Jan 3 16:22:39 2006 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <4.2.0.58.J.20031216160942.077942a8@localhost> References: <4.2.0.58.J.20031216160942.077942a8@localhost> Message-ID: <1071614605.15819.19.camel@felicia> tis 2003-12-16 klockan 22.32 skrev Martin Duerst: > I just by chance realized that you had removed the 'charset' > parameter from the registration for application/voicexml+xml, > and also for application/ssml+xml. I have found something similar > in other recent registration proposals. Now, wait a second here. Now there is Martin Duerst from W3.org telling us that we must indeed include a "charset" parameter with our foo/bar+xml MIME transport types. Then there is Chris Lilley of the same W3.org telling us *repeatedly* to remove it: > I suggest removing this optional parameter as follows: > > There is no charset parameter. Character handling has identical > semantics to the case where the charset parameter of the > "application/xml" media type is omitted, as described in > [RFC3023]. Now, I've been trusting Chris up til now, simply because he represents W3.org. You are of course welcome to run your internal disputes on the issue on these lists if you like, but when you're already at the same organizational body, could you *PLEASE* book an internal meeting and try to formulate a consensus from the W3.org side on how you think this thing should be handled? After all, you invented XML. Linus Walleij From: FYergeau at alis.com (Francois Yergeau) Date: Sun Dec 28 19:33:37 2003 Subject: proposed media type registration: application/voicexml+xml Message-ID: Seconded, for all the reasons given by Martin. Please restore the charset parameter. Regards, -- Fran?ois > -----Message d'origine----- > De : Martin Duerst [mailto:duerst@w3.org] > Envoy? : 16 d?cembre 2003 16:33 > ? : Max Froumentin; ietf-types@iana.org > Cc : w3c-archive@w3.org; ietf-xml-mime@imc.org; Ben Kovitz; Linus > Walleij > Objet : Re: proposed media type registration: application/voicexml+xml > > > > Hello Max, others, > > I just by chance realized that you had removed the 'charset' > parameter from the registration for application/voicexml+xml, > and also for application/ssml+xml. I have found something similar > in other recent registration proposals. > > Here is why I think this is really not a good idea: > > First, we start to get into a patchwork where some types > allow the 'charset', and others don't. Assuming that there > is something like generic XML processors (e.g. parsers) > (which is the whole point of XML), how should such a parser > know whether the 'charset' parameter is allowed or not, > and keep up with new registrations? > > Second, there are various scenarios a charset parameter in > the header is automatically generated, or where it's much > easier to generate it than to avoid it. The following are > examples: > - The classical example of transcoding (converting from one > encoding to another). Not very frequent these days on the > Web in general, but still used for Russian/Cyrillic encodings > and in some mobile phone scenarios. > - Scripting technologies, for example JSP. With JSP, it is much > more straightforward to produce output with the right encoding > with a 'charset' parameter in the header than without. The > reason for this is that JSP allows to produce any kind of > output, not limited to XML, and has to know how to convert > from the Java-internal encoding to whatever is used on the > wire. Putting that information in the 'charset' parameter > in the header then is straightforward; anything else has > to be done by hand. Hopefully, excluding certain classes > of content production technologies is not what you want. > - Databases that store content as characters rather than bytes, > in a single encoding (in many cases e.g. uniformly UTF-8), > and transcode on output. Again, if they use generic technology, > getting the 'charset' into the header is much more straightforward > than putting it into the body. > > Given all these cases, I think it's not at all appropriate to > remove the 'charset' parameter from the registration, because > it would severely limit the use of technology that in good > faith, and with good reasons, is using it. > > In the long run, I think that an update to RFC 3023 should address > these issues in more detail to help content producers understand the > advantages and problems related to charset/encoding information. > > Regards, Martin. > > > At 17:15 03/08/21 +0200, Max Froumentin wrote: > > >Hi, > > > >Please consider the attached Internet Draft submission: "The > >application/voicexml+xml Media Type" (originating from the Voice > >Browser Working Group of the W3C), for review. > > > >Cheers, > > > >Max Froumentin, W3C > >From ben@morrow.me.uk Sun Dec 28 20:30:43 2003 From: ben at morrow.me.uk (ben@morrow.me.uk) Date: Sun Dec 28 20:31:50 2003 Subject: Request for guidance on MIME and media types In-Reply-To: <7241C066-2CFF-11D8-8692-00039396E15A@bea.com> References: <7241C066-2CFF-11D8-8692-00039396E15A@bea.com> Message-ID: <20031228193043.GA6372@mauzo.mauzo.dyndns.org> At 4pm on 12/12/03 you (Mark Nottingham) wrote: > Note that a specification is being prepared that allows for > the use of a similar "resolve the URI to insert binary > characters" idiom in non-SOAP scenarios. The general > technique is documented at [3] under the working title "MTOM > Inclusion Format For You (MIFFY)", a title that will almost > surely change due to copyright issues. The proposed > application/soap_mtom+xml media type is thus a specific > example of the so-called Miffy class of encodings. We propose > that a media type be assigned to each such use of Miffy, with > application/soap_mtom+xml being assigned as the name for the > application of Miffy to SOAP envelopes. I entirely agree that a separate MIME type is appropriate; however, I would suggest a more generic name be used, such as application/soap+miffy+xml, with +miffy being generally used for application-of-Miffy-to-foo types. Ben -- If you put all the prophets, | You'd have so much more reason Mystics and saints | Than ever was born In one room together, | Out of all of the conflicts of time. ben@morrow.me.uk |----------------+---------------| The Levellers, 'Believers' >From triad@df.lth.se Sat Dec 6 21:57:20 2003 From: triad at df.lth.se (Linus Walleij) Date: Tue Jan 3 16:22:37 2006 Subject: Registration of MIME media type Application/EDI-Tradacoms In-Reply-To: <001101c3ace6$12870540$60eb3444@nash01.tn.comcast.net> References: <001101c3ace6$12870540$60eb3444@nash01.tn.comcast.net> Message-ID: <1070744239.16581.56.camel@felicia> m?n 2003-11-17 klockan 09.37 skrev Kyle Meadors: > MIME subtype name: IETF Tree - EDI-Tradacoms (...) > Published specification: Refer to RFC 1767 First, MIME transport types are lowercase as in "edi-tradacoms" Obviously there is some difference between "edi-tradacoms" and what is already in RFC 1767. If you want a registration in the IETF tree, then write an amendment RFC as well, or the registration will be ambiguous. If this is only in use by your company, consider using the vnd. namespace. Linus Walleij From: FYergeau at alis.com (Francois Yergeau) Date: Tue Jan 3 16:22:39 2006 Subject: proposed media type registration: application/voicexml+xml Message-ID: Seconded, for all the reasons given by Martin. Please restore the charset parameter. Regards, -- Fran?ois > -----Message d'origine----- > De : Martin Duerst [mailto:duerst@w3.org] > Envoy? : 16 d?cembre 2003 16:33 > ? : Max Froumentin; ietf-types@iana.org > Cc : w3c-archive@w3.org; ietf-xml-mime@imc.org; Ben Kovitz; Linus > Walleij > Objet : Re: proposed media type registration: application/voicexml+xml > > > > Hello Max, others, > > I just by chance realized that you had removed the 'charset' > parameter from the registration for application/voicexml+xml, > and also for application/ssml+xml. I have found something similar > in other recent registration proposals. > > Here is why I think this is really not a good idea: > > First, we start to get into a patchwork where some types > allow the 'charset', and others don't. Assuming that there > is something like generic XML processors (e.g. parsers) > (which is the whole point of XML), how should such a parser > know whether the 'charset' parameter is allowed or not, > and keep up with new registrations? > > Second, there are various scenarios a charset parameter in > the header is automatically generated, or where it's much > easier to generate it than to avoid it. The following are > examples: > - The classical example of transcoding (converting from one > encoding to another). Not very frequent these days on the > Web in general, but still used for Russian/Cyrillic encodings > and in some mobile phone scenarios. > - Scripting technologies, for example JSP. With JSP, it is much > more straightforward to produce output with the right encoding > with a 'charset' parameter in the header than without. The > reason for this is that JSP allows to produce any kind of > output, not limited to XML, and has to know how to convert > from the Java-internal encoding to whatever is used on the > wire. Putting that information in the 'charset' parameter > in the header then is straightforward; anything else has > to be done by hand. Hopefully, excluding certain classes > of content production technologies is not what you want. > - Databases that store content as characters rather than bytes, > in a single encoding (in many cases e.g. uniformly UTF-8), > and transcode on output. Again, if they use generic technology, > getting the 'charset' into the header is much more straightforward > than putting it into the body. > > Given all these cases, I think it's not at all appropriate to > remove the 'charset' parameter from the registration, because > it would severely limit the use of technology that in good > faith, and with good reasons, is using it. > > In the long run, I think that an update to RFC 3023 should address > these issues in more detail to help content producers understand the > advantages and problems related to charset/encoding information. > > Regards, Martin. > > > At 17:15 03/08/21 +0200, Max Froumentin wrote: > > >Hi, > > > >Please consider the attached Internet Draft submission: "The > >application/voicexml+xml Media Type" (originating from the Voice > >Browser Working Group of the W3C), for review. > > > >Cheers, > > > >Max Froumentin, W3C > From: mark.nottingham at bea.com (Mark Nottingham) Date: Tue Jan 3 16:22:39 2006 Subject: Request for guidance on MIME and media types Message-ID: <7241C066-2CFF-11D8-8692-00039396E15A@bea.com> The W3C XML Protocol Working Group is currently working on the Message Transmission Optimisation Mechanism (MTOM)[1], which allows more efficient transmission of SOAP envelopes [2] by changing their on-the-wire XML serialisation. Registration of the "application/soap+xml" media type is currently under way, so that SOAP envelopes (i.e. the XML construct that SOAP defines) can be identified in MIME and MIME-like systems. We anticipate the need to likewise identify MTOM messages in these systems, and would like to solicit guidance about the best way to do so. Whereas the XML 1.0 serialisation of SOAP is self-contained, MTOM serialisation will only use XML for a subset of the envelope data. Other portions of the envelope will be transmitted in separate binary entities, typically but not necessarily in a multipart/related MIME message, and those entities will be referenced with URIs from the envelope (which, when using multipart/related, would reside in the root part). A simplistic example might be; ---8<--- MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=MIME_boundary; type=application/soap_mtom+xml; start="" --MIME_boundary Content-Type: application/soap_mtom+xml Content-Transfer-Encoding: 8bit Content-ID: --MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: [binary image] --MIME_boundary-- ---8<--- Which could be transformed to this XML - ---8<--- [base64-encoded image] ---8<--- The XML that is transmitted by MTOM is thus distinct from application/soap+xml in at least the following respects: * It contains some but not all of the envelope data. Indeed, in the common case where multipart MIME is used, it's the entire package that conveys the same information as application/soap+xml. * Its semantics are different from those of a SOAP envelope. The usual semantic for a SOAP envelope is to apply the SOAP processing model; the semantics of an MTOM envelope are to to resolve the link URIs to create a new Infoset, which is in turn processable by the SOAP model. Therefore, it appears that the application/soap+xml media type, as currently defined, is not appropriate to describe the XML format created by MTOM. We've considered several possible alternatives, including 1) use of a HTTP content-coding (which we rejected, both because content-codings are a HTTP-specific mechanism, whereas we intend to use this encoding in other protocols, possibly including MIME-based protocols, and because doing so would require labelling the HTTP entity with an "application/soap+xml" media type, which would mask the presence of multipart MIME), and 2) a MIME content-transfer-encoding (which we rejected because registration of new CTEs is discouraged by RFC2045). Therefore, we believe that it would be most suitable to register a new media type, e.g., "application/soap_mtom+xml". This media type would identify the XML pre-MTOM processing (i.e., with the URIs to be referenced still embedded), possibly (but not necessarily) located inside a multipart/related package. Note that a specification is being prepared that allows for the use of a similar "resolve the URI to insert binary characters" idiom in non-SOAP scenarios. The general technique is documented at [3] under the working title "MTOM Inclusion Format For You (MIFFY)", a title that will almost surely change due to copyright issues. The proposed application/soap_mtom+xml media type is thus a specific example of the so-called Miffy class of encodings. We propose that a media type be assigned to each such use of Miffy, with application/soap_mtom+xml being assigned as the name for the application of Miffy to SOAP envelopes. We would appreciate any input as to whether this is the most appropriate way to flag the use of an alternate serialisation of an XML format in MIME, and/or pointers to guidance on this matter. 1. http://www.w3.org/TR/soap12-mtom/ 2. http://www.w3.org/TR/soap12-part0/ 3. http://www.w3.org/mid/DD037726-2236-11D8-836E-00039396E15A@bea.com -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems From: mf at w3.org (Max Froumentin) Date: Wed Dec 10 15:57:01 2003 Subject: proposed media type registration: application/voicexml+xml Message-ID: <87ptewu3gc.fsf@w3.org> Hi, Please consider the attached Internet Draft submission: "The application/voicexml+xml Media Type" (originating from the Voice Browser Working Group of the W3C), for review. Cheers, Max Froumentin, W3C -------------- next part -------------- Network Working Group M. Froumentin INTERNET DRAFT W3C draft-froumentin-voicexml-media-type-01.txt December 2003 The application/voicexml+xml Media Type Status of this Memo This document is anhttp://www.ietf.org/rfc/rfc2026.txt Internet-Draft and is subject to all provisions of Section 10 of RFC2026. http://www.ietf.org/rfc/rfc2026.txt Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents ashttp://www.ietf.org/rfc/rfc2026.txt Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document specifies the Media Type for the W3C Voice Extensible Markup Language (VoiceXML), version 2.0. VoiceXML is an XML markup language designed for creating audio dialogs that feature synthesized speech, digitized audio, recognition of spoken and DTMF key input, recording of spoken input, telephony, and mixed-initiative conversations. Expires: June 2004 1. Introduction The World Wide Web Consortium has issued a specification [VXML] defining the Voice Extensible Markup Language (VoiceXML), version 2.0. This memo provides information about the application/voicexml+xml Media Type, intended to be used for transferring VoiceXML documents. This document follows the convention set out in [XMLMIME] for the MIME subtype name; attaching the suffix "+xml" to denote that the entity being described conforms to the XML syntax as defined in XML 1.0 [XML]. This document was prepared by members of the W3C Voice Browser working group. Please send comments to www-voice@w3.org, a public mailing list with archives at . 2. Registration of MIME media type application/voicexml+xml MIME media type name: application MIME subtype name: voicexml+xml Required parameters: none Optional parameters: none Encoding considerations: See Section 4 of this document. Security considerations: See Section 7 of this document. Interoperability considerations: VoiceXML [VXML] specifies user agent conformance rules that dictate behaviour that must be followed when dealing with, among other things, unrecognized elements. Published specification: VoiceXML 2.0 is now defined as a W3C Recommendation; the latest published versions is at [VoiceXML]. Applications which use this media type: Some content authors have already begun hand and tool authoring on the Web with VoiceXML. However that content is currently described as "text/xml" or "application/xml", allowing existing Web browsers to process it without reconfiguration for a new media type. This new type is being registered in order to allow for the expected deployment of VoiceXML on the World Wide Web, as a first class XML application where authors can expect that user agents are conformant XML 1.0 [XML] processors. Additional information: Magic number: There is no single initial byte sequence that is always present for VoiceXML files. However, Section 5 below gives some guidelines for recognizing VoiceXML files. See also section 3.1 in [XMLMIME]. File extension: There most common file extension that is currently in use for VoiceXML is ".vxml". Macintosh File Type code: TEXT Person & email address to contact for further information: Max Froumentin Intended usage: COMMON Author/Change controller: The VoiceXML 2.0 specification is a work product of the World Wide Web Consortium's Voice Browser Working Group. The W3C has change control over these specifications. 3. Encoding considerations By virtue of VoiceXML content being XML, it has the same considerations when sent as 'application/voicexml+xml' as does XML. See [XMLMIME], section 3.2. 4. Recognizing VoiceXML files All VoiceXML documents will have the string ". [XML] "Extensible Markup Language (XML) 1.0", W3C Recommendation. Available at (or ). [XMLMIME] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. 10. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. >From mf@w3.org Wed Dec 10 17:41:40 2003 From: mf at w3.org (Max Froumentin) Date: Wed Dec 10 17:41:51 2003 Subject: proposed media type registration: application/ssml+xml In-Reply-To: <87ptewu3gc.fsf@w3.org> (Max Froumentin's message of "Thu, 21 Aug 2003 17:15:04 +0200") References: <87ptewu3gc.fsf@w3.org> Message-ID: <87iskotykb.fsf@w3.org> Hi, Please consider the attached Internet Draft submission: "The application/ssml+xml Media Type" (originating from the Voice Browser Working Group of the W3C), for review. Cheers, Max Froumentin, W3C -------------- next part -------------- Network Working Group M. Froumentin INTERNET DRAFT W3C draft-froumentin-ssml-media-type.txt December 2003 The application/ssml+xml Media Type Status of this Memo This document is anhttp://www.ietf.org/rfc/rfc2026.txt Internet-Draft and is subject to all provisions of Section 10 of RFC2026. http://www.ietf.org/rfc/rfc2026.txt Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents ashttp://www.ietf.org/rfc/rfc2026.txt Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document specifies the Media Type for the W3C Speech Synthesis Markup Language (SSML). Speech Synthesis Markup Language is an XML based markup language for assisting the generation of synthetic speech in web and other applications. The essential role of SSML is to give authors of synthesizable content a standard way to control aspects of speech output such as pronunciation, volume, pitch, rate and etc. across different synthesis-capable platforms. Expires: June 2004 1. Introduction The World Wide Web Consortium has issued a specification [SSML] defining the Speech Synthesis Markup Language (SSML). This memo provides information about the application/ssml+xml Media Type, intended to be used for transferring SSML documents. This document follows the convention set out in [XMLMIME] for the MIME subtype name; attaching the suffix "+xml" to denote that the entity being described conforms to the XML syntax as defined in XML 1.0 [XML]. This document was prepared by members of the W3C Voice Browser working group. Please send comments to www-voice@w3.org, a public mailing list with archives at . 2. Registration of MIME media type application/ssml+xml MIME media type name: application MIME subtype name: ssml+xml Required parameters: none Optional parameters: none Encoding considerations: See Section 4 of this document. Security considerations: See Section 7 of this document. Interoperability considerations: SSML [SSML] specifies user agent conformance rules that dictate behaviour that must be followed when dealing with, among other things, unrecognized elements. Published specification: SSML is now defined as a W3C specification; the latest published versions is at [SSML]. Applications which use this media type: Some content authors have already begun hand and tool authoring on the Web with SSML. However that content is currently described as "text/xml" or "application/xml", allowing existing Web browsers to process it without reconfiguration for a new media type. This new type is being registered in order to allow for the expected deployment of SSML on the World Wide Web, as a first class XML application where authors can expect that user agents are conformant XML 1.0 [XML] processors. Additional information: Magic number: There is no single initial byte sequence that is always present for SSML files. However, Section 5 below gives some guidelines for recognizing SSML files. See also section 3.1 in [XMLMIME]. File extension: There most common file extension that is currently in use for SSML is ".ssml". Macintosh File Type code: TEXT Person & email address to contact for further information: Max Froumentin Intended usage: COMMON Author/Change controller: The SSML 1.0 specification is a work product of the World Wide Web Consortium's Voice Browser Working Group. The W3C has change control over these specifications. 3. Encoding considerations By virtue of SSML content being XML, it has the same considerations when sent as 'application/ssml+xml' as does XML. See [XMLMIME], section 3.2. 4. Recognizing SSML files All SSML documents will have the string ". [XML] "Extensible Markup Language (XML) 1.0", W3C Recommendation. Available at (or ). [XMLMIME] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. 10. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. >From duerst@w3.org Tue Dec 16 22:32:59 2003 From: duerst at w3.org (Martin Duerst) Date: Tue Dec 16 22:34:23 2003 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <87ptewu3gc.fsf@w3.org> Message-ID: <4.2.0.58.J.20031216160942.077942a8@localhost> Hello Max, others, I just by chance realized that you had removed the 'charset' parameter from the registration for application/voicexml+xml, and also for application/ssml+xml. I have found something similar in other recent registration proposals. Here is why I think this is really not a good idea: First, we start to get into a patchwork where some types allow the 'charset', and others don't. Assuming that there is something like generic XML processors (e.g. parsers) (which is the whole point of XML), how should such a parser know whether the 'charset' parameter is allowed or not, and keep up with new registrations? Second, there are various scenarios a charset parameter in the header is automatically generated, or where it's much easier to generate it than to avoid it. The following are examples: - The classical example of transcoding (converting from one encoding to another). Not very frequent these days on the Web in general, but still used for Russian/Cyrillic encodings and in some mobile phone scenarios. - Scripting technologies, for example JSP. With JSP, it is much more straightforward to produce output with the right encoding with a 'charset' parameter in the header than without. The reason for this is that JSP allows to produce any kind of output, not limited to XML, and has to know how to convert from the Java-internal encoding to whatever is used on the wire. Putting that information in the 'charset' parameter in the header then is straightforward; anything else has to be done by hand. Hopefully, excluding certain classes of content production technologies is not what you want. - Databases that store content as characters rather than bytes, in a single encoding (in many cases e.g. uniformly UTF-8), and transcode on output. Again, if they use generic technology, getting the 'charset' into the header is much more straightforward than putting it into the body. Given all these cases, I think it's not at all appropriate to remove the 'charset' parameter from the registration, because it would severely limit the use of technology that in good faith, and with good reasons, is using it. In the long run, I think that an update to RFC 3023 should address these issues in more detail to help content producers understand the advantages and problems related to charset/encoding information. Regards, Martin. At 17:15 03/08/21 +0200, Max Froumentin wrote: >Hi, > >Please consider the attached Internet Draft submission: "The >application/voicexml+xml Media Type" (originating from the Voice >Browser Working Group of the W3C), for review. > >Cheers, > >Max Froumentin, W3C From: mf at w3.org (Max Froumentin) Date: Tue Jan 3 16:22:38 2006 Subject: proposed media type registration: application/voicexml+xml Message-ID: <87ptewu3gc.fsf@w3.org> Hi, Please consider the attached Internet Draft submission: "The application/voicexml+xml Media Type" (originating from the Voice Browser Working Group of the W3C), for review. Cheers, Max Froumentin, W3C -------------- next part -------------- Network Working Group M. Froumentin INTERNET DRAFT W3C draft-froumentin-voicexml-media-type-01.txt December 2003 The application/voicexml+xml Media Type Status of this Memo This document is anhttp://www.ietf.org/rfc/rfc2026.txt Internet-Draft and is subject to all provisions of Section 10 of RFC2026. http://www.ietf.org/rfc/rfc2026.txt Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents ashttp://www.ietf.org/rfc/rfc2026.txt Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document specifies the Media Type for the W3C Voice Extensible Markup Language (VoiceXML), version 2.0. VoiceXML is an XML markup language designed for creating audio dialogs that feature synthesized speech, digitized audio, recognition of spoken and DTMF key input, recording of spoken input, telephony, and mixed-initiative conversations. Expires: June 2004 1. Introduction The World Wide Web Consortium has issued a specification [VXML] defining the Voice Extensible Markup Language (VoiceXML), version 2.0. This memo provides information about the application/voicexml+xml Media Type, intended to be used for transferring VoiceXML documents. This document follows the convention set out in [XMLMIME] for the MIME subtype name; attaching the suffix "+xml" to denote that the entity being described conforms to the XML syntax as defined in XML 1.0 [XML]. This document was prepared by members of the W3C Voice Browser working group. Please send comments to www-voice@w3.org, a public mailing list with archives at . 2. Registration of MIME media type application/voicexml+xml MIME media type name: application MIME subtype name: voicexml+xml Required parameters: none Optional parameters: none Encoding considerations: See Section 4 of this document. Security considerations: See Section 7 of this document. Interoperability considerations: VoiceXML [VXML] specifies user agent conformance rules that dictate behaviour that must be followed when dealing with, among other things, unrecognized elements. Published specification: VoiceXML 2.0 is now defined as a W3C Recommendation; the latest published versions is at [VoiceXML]. Applications which use this media type: Some content authors have already begun hand and tool authoring on the Web with VoiceXML. However that content is currently described as "text/xml" or "application/xml", allowing existing Web browsers to process it without reconfiguration for a new media type. This new type is being registered in order to allow for the expected deployment of VoiceXML on the World Wide Web, as a first class XML application where authors can expect that user agents are conformant XML 1.0 [XML] processors. Additional information: Magic number: There is no single initial byte sequence that is always present for VoiceXML files. However, Section 5 below gives some guidelines for recognizing VoiceXML files. See also section 3.1 in [XMLMIME]. File extension: There most common file extension that is currently in use for VoiceXML is ".vxml". Macintosh File Type code: TEXT Person & email address to contact for further information: Max Froumentin Intended usage: COMMON Author/Change controller: The VoiceXML 2.0 specification is a work product of the World Wide Web Consortium's Voice Browser Working Group. The W3C has change control over these specifications. 3. Encoding considerations By virtue of VoiceXML content being XML, it has the same considerations when sent as 'application/voicexml+xml' as does XML. See [XMLMIME], section 3.2. 4. Recognizing VoiceXML files All VoiceXML documents will have the string ". [XML] "Extensible Markup Language (XML) 1.0", W3C Recommendation. Available at (or ). [XMLMIME] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. 10. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. >From mf@w3.org Wed Dec 10 17:41:40 2003 From: mf at w3.org (Max Froumentin) Date: Tue Jan 3 16:22:38 2006 Subject: proposed media type registration: application/ssml+xml In-Reply-To: <87ptewu3gc.fsf@w3.org> (Max Froumentin's message of "Thu, 21 Aug 2003 17:15:04 +0200") References: <87ptewu3gc.fsf@w3.org> Message-ID: <87iskotykb.fsf@w3.org> Hi, Please consider the attached Internet Draft submission: "The application/ssml+xml Media Type" (originating from the Voice Browser Working Group of the W3C), for review. Cheers, Max Froumentin, W3C -------------- next part -------------- Network Working Group M. Froumentin INTERNET DRAFT W3C draft-froumentin-ssml-media-type.txt December 2003 The application/ssml+xml Media Type Status of this Memo This document is anhttp://www.ietf.org/rfc/rfc2026.txt Internet-Draft and is subject to all provisions of Section 10 of RFC2026. http://www.ietf.org/rfc/rfc2026.txt Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents ashttp://www.ietf.org/rfc/rfc2026.txt Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document specifies the Media Type for the W3C Speech Synthesis Markup Language (SSML). Speech Synthesis Markup Language is an XML based markup language for assisting the generation of synthetic speech in web and other applications. The essential role of SSML is to give authors of synthesizable content a standard way to control aspects of speech output such as pronunciation, volume, pitch, rate and etc. across different synthesis-capable platforms. Expires: June 2004 1. Introduction The World Wide Web Consortium has issued a specification [SSML] defining the Speech Synthesis Markup Language (SSML). This memo provides information about the application/ssml+xml Media Type, intended to be used for transferring SSML documents. This document follows the convention set out in [XMLMIME] for the MIME subtype name; attaching the suffix "+xml" to denote that the entity being described conforms to the XML syntax as defined in XML 1.0 [XML]. This document was prepared by members of the W3C Voice Browser working group. Please send comments to www-voice@w3.org, a public mailing list with archives at . 2. Registration of MIME media type application/ssml+xml MIME media type name: application MIME subtype name: ssml+xml Required parameters: none Optional parameters: none Encoding considerations: See Section 4 of this document. Security considerations: See Section 7 of this document. Interoperability considerations: SSML [SSML] specifies user agent conformance rules that dictate behaviour that must be followed when dealing with, among other things, unrecognized elements. Published specification: SSML is now defined as a W3C specification; the latest published versions is at [SSML]. Applications which use this media type: Some content authors have already begun hand and tool authoring on the Web with SSML. However that content is currently described as "text/xml" or "application/xml", allowing existing Web browsers to process it without reconfiguration for a new media type. This new type is being registered in order to allow for the expected deployment of SSML on the World Wide Web, as a first class XML application where authors can expect that user agents are conformant XML 1.0 [XML] processors. Additional information: Magic number: There is no single initial byte sequence that is always present for SSML files. However, Section 5 below gives some guidelines for recognizing SSML files. See also section 3.1 in [XMLMIME]. File extension: There most common file extension that is currently in use for SSML is ".ssml". Macintosh File Type code: TEXT Person & email address to contact for further information: Max Froumentin Intended usage: COMMON Author/Change controller: The SSML 1.0 specification is a work product of the World Wide Web Consortium's Voice Browser Working Group. The W3C has change control over these specifications. 3. Encoding considerations By virtue of SSML content being XML, it has the same considerations when sent as 'application/ssml+xml' as does XML. See [XMLMIME], section 3.2. 4. Recognizing SSML files All SSML documents will have the string ". [XML] "Extensible Markup Language (XML) 1.0", W3C Recommendation. Available at (or ). [XMLMIME] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001. 10. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. >From duerst@w3.org Tue Dec 16 22:32:59 2003 From: duerst at w3.org (Martin Duerst) Date: Tue Jan 3 16:22:38 2006 Subject: proposed media type registration: application/voicexml+xml In-Reply-To: <87ptewu3gc.fsf@w3.org> Message-ID: <4.2.0.58.J.20031216160942.077942a8@localhost> Hello Max, others, I just by chance realized that you had removed the 'charset' parameter from the registration for application/voicexml+xml, and also for application/ssml+xml. I have found something similar in other recent registration proposals. Here is why I think this is really not a good idea: First, we start to get into a patchwork where some types allow the 'charset', and others don't. Assuming that there is something like generic XML processors (e.g. parsers) (which is the whole point of XML), how should such a parser know whether the 'charset' parameter is allowed or not, and keep up with new registrations? Second, there are various scenarios a charset parameter in the header is automatically generated, or where it's much easier to generate it than to avoid it. The following are examples: - The classical example of transcoding (converting from one encoding to another). Not very frequent these days on the Web in general, but still used for Russian/Cyrillic encodings and in some mobile phone scenarios. - Scripting technologies, for example JSP. With JSP, it is much more straightforward to produce output with the right encoding with a 'charset' parameter in the header than without. The reason for this is that JSP allows to produce any kind of output, not limited to XML, and has to know how to convert from the Java-internal encoding to whatever is used on the wire. Putting that information in the 'charset' parameter in the header then is straightforward; anything else has to be done by hand. Hopefully, excluding certain classes of content production technologies is not what you want. - Databases that store content as characters rather than bytes, in a single encoding (in many cases e.g. uniformly UTF-8), and transcode on output. Again, if they use generic technology, getting the 'charset' into the header is much more straightforward than putting it into the body. Given all these cases, I think it's not at all appropriate to remove the 'charset' parameter from the registration, because it would severely limit the use of technology that in good faith, and with good reasons, is using it. In the long run, I think that an update to RFC 3023 should address these issues in more detail to help content producers understand the advantages and problems related to charset/encoding information. Regards, Martin. At 17:15 03/08/21 +0200, Max Froumentin wrote: >Hi, > >Please consider the attached Internet Draft submission: "The >application/voicexml+xml Media Type" (originating from the Voice >Browser Working Group of the W3C), for review. > >Cheers, > >Max Froumentin, W3C From: moore at cs.utk.edu (Keith Moore) Date: Mon Dec 8 07:08:57 2003 Subject: please review 'application/pdf' In-Reply-To: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40> References: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40> Message-ID: <11DFD398-2945-11D8-97F7-000393DB5366@cs.utk.edu> Larry, Thinking about this some more - There are lots of protocols that specify things like access permissions - NFS for instance. We don't have a problem with these. But we don't try to equate NFS permissions with copyright restrictions, nor do we threaten NFS implementors whose implementations allow users to ignore or circumvent those permissions. There are several good reasons for ignoring or circumventing those permissions, and we don't expect computer programs to be able to distinguish the cases where there are good reasons from those where the reasons are bad - indeed we cannot anticipate all of the good reasons in advance. In most 2-party protocols we expect 'server' hosts to protect resources on those hosts, acting in the interests of the server. We expect client programs to act in the interest of the client, not those of the content provider. We would regard any design that provided a way for clients to break access permissions, and merely trusted them not to do so, as unsound. (For instance, this is why use of source port numbers < 1024 to prove that you're privileged isn't acceptable.) Here's how I think this breaks down: If Adobe wants to point out that there is such a thing as access permissions in PDF, that's merely providing information which might be useful to the reader. If Adobe wants to claim that circumventing or ignoring these permissions is violating copyright law, that is at best an exaggeration and at worst dangerously misleading for a variety of reasons. IETF should not lend its imprimatur to such statements. If Adobe is going to try to legally screw anyone who implements PDF in a way that doesn't enforce access permissions, then giving potential implementors warning of that policy in the media type registration is in some sense the least Adobe could do. And if the mechanism by which Adobe hopes to screw such implementors is by claiming that the implementors are violating their "copyright" on data structures, this is pretty similar to reasons that we have IPR statements in other documents. Just as with patent claims, IETF shouldn't make any comment on the legal validity of this theory. But if Adobe is going to have that policy, I don't think IETF should be helping to promote PDF by publishing this as an RFC - the most we should do is update the media-type registration. Furthermore, IETF should stop supporting the use of PDF in Internet-Drafts and RFCs, in favor of some other format that is freely usable. From: moore at cs.utk.edu (Keith Moore) Date: Tue Jan 3 16:22:38 2006 Subject: please review 'application/pdf' In-Reply-To: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40> References: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40> Message-ID: <11DFD398-2945-11D8-97F7-000393DB5366@cs.utk.edu> Larry, Thinking about this some more - There are lots of protocols that specify things like access permissions - NFS for instance. We don't have a problem with these. But we don't try to equate NFS permissions with copyright restrictions, nor do we threaten NFS implementors whose implementations allow users to ignore or circumvent those permissions. There are several good reasons for ignoring or circumventing those permissions, and we don't expect computer programs to be able to distinguish the cases where there are good reasons from those where the reasons are bad - indeed we cannot anticipate all of the good reasons in advance. In most 2-party protocols we expect 'server' hosts to protect resources on those hosts, acting in the interests of the server. We expect client programs to act in the interest of the client, not those of the content provider. We would regard any design that provided a way for clients to break access permissions, and merely trusted them not to do so, as unsound. (For instance, this is why use of source port numbers < 1024 to prove that you're privileged isn't acceptable.) Here's how I think this breaks down: If Adobe wants to point out that there is such a thing as access permissions in PDF, that's merely providing information which might be useful to the reader. If Adobe wants to claim that circumventing or ignoring these permissions is violating copyright law, that is at best an exaggeration and at worst dangerously misleading for a variety of reasons. IETF should not lend its imprimatur to such statements. If Adobe is going to try to legally screw anyone who implements PDF in a way that doesn't enforce access permissions, then giving potential implementors warning of that policy in the media type registration is in some sense the least Adobe could do. And if the mechanism by which Adobe hopes to screw such implementors is by claiming that the implementors are violating their "copyright" on data structures, this is pretty similar to reasons that we have IPR statements in other documents. Just as with patent claims, IETF shouldn't make any comment on the legal validity of this theory. But if Adobe is going to have that policy, I don't think IETF should be helping to promote PDF by publishing this as an RFC - the most we should do is update the media-type registration. Furthermore, IETF should stop supporting the use of PDF in Internet-Drafts and RFCs, in favor of some other format that is freely usable. From: moore at cs.utk.edu (Keith Moore) Date: Mon Dec 8 03:47:32 2003 Subject: please review 'application/pdf' In-Reply-To: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40> References: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40> Message-ID: On Dec 7, 2003, at 8:08 PM, Larry Masinter wrote: >>> In HTTP, the "cache-control: private" directive is defined >>> with normative language for HTTP implementations about which >>> bits they may or may not "share" with other users. >> >> clever, but it's not quite the same thing. cache-control limits what >> an HTTP intermediary can do with the file, but doesn't place any >> restrictions on the user. > > So you would be satisfied if the document expressed the constraint > in terms of behavior of the implementations, rather than a constraint > on the users of those implementations? no, of course not. cache-control exists for cache coherency; it doesn't limit what the user can do with the file. however, the constraints in PDF are intended to impose restrictions beyond those which are supported, and in some cases even beyond those allowed by law. it's trying to replace laws that were crafted as compromises between the needs of the public vs. the needs of the content owner, with constraints that are solely determined by the creator of the PDF file. that's seriously wrong. From: moore at cs.utk.edu (Keith Moore) Date: Tue Jan 3 16:22:38 2006 Subject: please review 'application/pdf' In-Reply-To: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40> References: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40> Message-ID: On Dec 7, 2003, at 8:08 PM, Larry Masinter wrote: >>> In HTTP, the "cache-control: private" directive is defined >>> with normative language for HTTP implementations about which >>> bits they may or may not "share" with other users. >> >> clever, but it's not quite the same thing. cache-control limits what >> an HTTP intermediary can do with the file, but doesn't place any >> restrictions on the user. > > So you would be satisfied if the document expressed the constraint > in terms of behavior of the implementations, rather than a constraint > on the users of those implementations? no, of course not. cache-control exists for cache coherency; it doesn't limit what the user can do with the file. however, the constraints in PDF are intended to impose restrictions beyond those which are supported, and in some cases even beyond those allowed by law. it's trying to replace laws that were crafted as compromises between the needs of the public vs. the needs of the content owner, with constraints that are solely determined by the creator of the PDF file. that's seriously wrong. From: LMM at acm.org (Larry Masinter) Date: Mon Dec 8 02:09:10 2003 Subject: please review 'application/pdf' In-Reply-To: Message-ID: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40> > > In HTTP, the "cache-control: private" directive is defined > > with normative language for HTTP implementations about which > > bits they may or may not "share" with other users. > > clever, but it's not quite the same thing. cache-control limits what > an HTTP intermediary can do with the file, but doesn't place any > restrictions on the user. So you would be satisfied if the document expressed the constraint in terms of behavior of the implementations, rather than a constraint on the users of those implementations? Larry -- http://larry.masinter.net From: LMM at acm.org (Larry Masinter) Date: Tue Jan 3 16:22:38 2006 Subject: please review 'application/pdf' In-Reply-To: Message-ID: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40> > > In HTTP, the "cache-control: private" directive is defined > > with normative language for HTTP implementations about which > > bits they may or may not "share" with other users. > > clever, but it's not quite the same thing. cache-control limits what > an HTTP intermediary can do with the file, but doesn't place any > restrictions on the user. So you would be satisfied if the document expressed the constraint in terms of behavior of the implementations, rather than a constraint on the users of those implementations? Larry -- http://larry.masinter.net From: moore at cs.utk.edu (Keith Moore) Date: Sun Dec 7 16:18:57 2003 Subject: please review 'application/pdf' In-Reply-To: <000a01c3bc8d$04cf2200$6801a8c0@MasinterT40> References: <000a01c3bc8d$04cf2200$6801a8c0@MasinterT40> Message-ID: > In HTTP, the "cache-control: private" directive is defined > with normative language for HTTP implementations about which > bits they may or may not "share" with other users. clever, but it's not quite the same thing. cache-control limits what an HTTP intermediary can do with the file, but doesn't place any restrictions on the user. From: moore at cs.utk.edu (Keith Moore) Date: Tue Jan 3 16:22:38 2006 Subject: please review 'application/pdf' In-Reply-To: <000a01c3bc8d$04cf2200$6801a8c0@MasinterT40> References: <000a01c3bc8d$04cf2200$6801a8c0@MasinterT40> Message-ID: > In HTTP, the "cache-control: private" directive is defined > with normative language for HTTP implementations about which > bits they may or may not "share" with other users. clever, but it's not quite the same thing. cache-control limits what an HTTP intermediary can do with the file, but doesn't place any restrictions on the user. From: LMM at acm.org (Larry Masinter) Date: Sun Dec 7 07:41:30 2003 Subject: please review 'application/pdf' In-Reply-To: <55E97D9A-2867-11D8-97F7-000393DB5366@cs.utk.edu> Message-ID: <000a01c3bc8d$04cf2200$6801a8c0@MasinterT40> > > In the end, it's just a file format that includes an > > some ACL bits. It seems legitimate to describe what > > ACL bits are intended to mean in a description of > > a protocol or protocol element or file format, > > whatever the mechanisms might be for actual enforcement > > of those bits. > > yup. just as long as there isn't any statement to the effect that > implementations are expected to honor those bits. In HTTP, the "cache-control: private" directive is defined with normative language for HTTP implementations about which bits they may or may not "share" with other users. Shared cache implementations are expected to honor "cache-control: private"; those that disregard the directive are non-compliant. Larry From: LMM at acm.org (Larry Masinter) Date: Tue Jan 3 16:22:38 2006 Subject: please review 'application/pdf' In-Reply-To: <55E97D9A-2867-11D8-97F7-000393DB5366@cs.utk.edu> Message-ID: <000a01c3bc8d$04cf2200$6801a8c0@MasinterT40> > > In the end, it's just a file format that includes an > > some ACL bits. It seems legitimate to describe what > > ACL bits are intended to mean in a description of > > a protocol or protocol element or file format, > > whatever the mechanisms might be for actual enforcement > > of those bits. > > yup. just as long as there isn't any statement to the effect that > implementations are expected to honor those bits. In HTTP, the "cache-control: private" directive is defined with normative language for HTTP implementations about which bits they may or may not "share" with other users. Shared cache implementations are expected to honor "cache-control: private"; those that disregard the directive are non-compliant. Larry From: moore at cs.utk.edu (Keith Moore) Date: Sun Dec 7 04:41:39 2003 Subject: please review 'application/pdf' In-Reply-To: <000601c3bc73$5eb643d0$6801a8c0@MasinterT40> References: <000601c3bc73$5eb643d0$6801a8c0@MasinterT40> Message-ID: <55E97D9A-2867-11D8-97F7-000393DB5366@cs.utk.edu> > In the end, it's just a file format that includes an > some ACL bits. It seems legitimate to describe what > ACL bits are intended to mean in a description of > a protocol or protocol element or file format, > whatever the mechanisms might be for actual enforcement > of those bits. yup. just as long as there isn't any statement to the effect that implementations are expected to honor those bits. Keith From: moore at cs.utk.edu (Keith Moore) Date: Tue Jan 3 16:22:38 2006 Subject: please review 'application/pdf' In-Reply-To: <000601c3bc73$5eb643d0$6801a8c0@MasinterT40> References: <000601c3bc73$5eb643d0$6801a8c0@MasinterT40> Message-ID: <55E97D9A-2867-11D8-97F7-000393DB5366@cs.utk.edu> > In the end, it's just a file format that includes an > some ACL bits. It seems legitimate to describe what > ACL bits are intended to mean in a description of > a protocol or protocol element or file format, > whatever the mechanisms might be for actual enforcement > of those bits. yup. just as long as there isn't any statement to the effect that implementations are expected to honor those bits. Keith From: LMM at acm.org (Larry Masinter) Date: Tue Jan 3 16:22:38 2006 Subject: please review 'application/pdf' In-Reply-To: <20031206214522.7fd726bc.moore@cs.utk.edu> Message-ID: <000601c3bc73$5eb643d0$6801a8c0@MasinterT40> It's pretty clear that the quoted statement should be changed in an updated internet draft. It seems important to make clear that the bits in the file may be used to specify the creator's intent, but there is should be no presumption of giving any kind of legal advice about "rights", whether or not those rights are related to copyright or any other kind of right. In the end, it's just a file format that includes an some ACL bits. It seems legitimate to describe what ACL bits are intended to mean in a description of a protocol or protocol element or file format, whatever the mechanisms might be for actual enforcement of those bits. Larry From: moore at cs.utk.edu (Keith Moore) Date: Sun Dec 7 03:53:30 2003 Subject: please review 'application/pdf' In-Reply-To: <532468549.20031024001316@w3.org> References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> Message-ID: <20031206214522.7fd726bc.moore@cs.utk.edu> catching up on some very old mail here: > I also see > > o Accessing the document in ways not permitted by the document's > access permissions is a violation of the document author's > copyright. > > This strikes me as a useful statement and I am pleased by its > inclusion. I'm going to add my voice to those who believe it's inappropriate for this statement to be in here. * One reason that the statement is inapppropriate is that it's false. * Copyright, at least in countries that signed Berne convention, assigns certain discrete rights that are not aligned with the access permissions described in a PDF document. These rights may be assigned exclusively (sold) or non-exclusively (licensed), and independently of one another. The fact that the creator of a PDF document has asserted permissions on the use of that document should not be taken as prima facia evidence that the owner of the copyright associated with the document has assigned the right to the document's creator to permit such access. In effect, PDF gives the document's creator the abliity to claim rights (to permit or deny various kinds of access to the document) that he may not possess. There is no reason to assume that the access rights indicated in the PDF document are consistent with the rights granted by the copyright holder to the document creator. Furthermore, in most countries, there are limitations on those rights, both in that they are time-limited and in that there are exceptions such as for fair use. Those limitations vary from one country to another, and are changed from time to time. It is not in violation of copyright law for a program to permit access that is legally permitted in his jurisdiction, whether this is because the copyright has expired, or because it falls under fair use, or for other reasons. At least in the United States, copyright was intended to strike a balance between the interests of the public in having works freely available and the interests in content creators in having an incentive to produce new works. I've always said that I'll support DRM when it preserves the rights of the public equally as well as it preserves the rights of the copyright holder, including the fact that those rights change from one jurisdiction to another and over time. PDF doesn't even try to do that - it tries to tip the balance away from the public. Frankly, given what is at stake here, I find the effort to get IETF to endorse this kind of rip off EXTREMELY OFFENSIVE and I will do whatever I can to encourage IESG and/or the RFC editor to withhold publication, as long as such offensive statements remain in the document. I also find Adobe's claims on copyright of the data structures used in PDF to be dubious at best, given my understanding of copyright law, and I don't believe the IETF should lend its imprimatur to such claims. By introducing DRM into PDF, Adobe has done great harm to the suitability of PDF as a document format (particularly for archive purposes), and also to the public interest. IETF should not support this effort. Keith >From LMM@acm.org Sun Dec 7 04:36:58 2003 From: LMM at acm.org (Larry Masinter) Date: Sun Dec 7 04:37:22 2003 Subject: please review 'application/pdf' In-Reply-To: <20031206214522.7fd726bc.moore@cs.utk.edu> Message-ID: <000601c3bc73$5eb643d0$6801a8c0@MasinterT40> It's pretty clear that the quoted statement should be changed in an updated internet draft. It seems important to make clear that the bits in the file may be used to specify the creator's intent, but there is should be no presumption of giving any kind of legal advice about "rights", whether or not those rights are related to copyright or any other kind of right. In the end, it's just a file format that includes an some ACL bits. It seems legitimate to describe what ACL bits are intended to mean in a description of a protocol or protocol element or file format, whatever the mechanisms might be for actual enforcement of those bits. Larry From: moore at cs.utk.edu (Keith Moore) Date: Tue Jan 3 16:22:38 2006 Subject: please review 'application/pdf' In-Reply-To: <532468549.20031024001316@w3.org> References: <000001c399a8$ed849370$c3432099@MasinterT40> <532468549.20031024001316@w3.org> Message-ID: <20031206214522.7fd726bc.moore@cs.utk.edu> catching up on some very old mail here: > I also see > > o Accessing the document in ways not permitted by the document's > access permissions is a violation of the document author's > copyright. > > This strikes me as a useful statement and I am pleased by its > inclusion. I'm going to add my voice to those who believe it's inappropriate for this statement to be in here. * One reason that the statement is inapppropriate is that it's false. * Copyright, at least in countries that signed Berne convention, assigns certain discrete rights that are not aligned with the access permissions described in a PDF document. These rights may be assigned exclusively (sold) or non-exclusively (licensed), and independently of one another. The fact that the creator of a PDF document has asserted permissions on the use of that document should not be taken as prima facia evidence that the owner of the copyright associated with the document has assigned the right to the document's creator to permit such access. In effect, PDF gives the document's creator the abliity to claim rights (to permit or deny various kinds of access to the document) that he may not possess. There is no reason to assume that the access rights indicated in the PDF document are consistent with the rights granted by the copyright holder to the document creator. Furthermore, in most countries, there are limitations on those rights, both in that they are time-limited and in that there are exceptions such as for fair use. Those limitations vary from one country to another, and are changed from time to time. It is not in violation of copyright law for a program to permit access that is legally permitted in his jurisdiction, whether this is because the copyright has expired, or because it falls under fair use, or for other reasons. At least in the United States, copyright was intended to strike a balance between the interests of the public in having works freely available and the interests in content creators in having an incentive to produce new works. I've always said that I'll support DRM when it preserves the rights of the public equally as well as it preserves the rights of the copyright holder, including the fact that those rights change from one jurisdiction to another and over time. PDF doesn't even try to do that - it tries to tip the balance away from the public. Frankly, given what is at stake here, I find the effort to get IETF to endorse this kind of rip off EXTREMELY OFFENSIVE and I will do whatever I can to encourage IESG and/or the RFC editor to withhold publication, as long as such offensive statements remain in the document. I also find Adobe's claims on copyright of the data structures used in PDF to be dubious at best, given my understanding of copyright law, and I don't believe the IETF should lend its imprimatur to such claims. By introducing DRM into PDF, Adobe has done great harm to the suitability of PDF as a document format (particularly for archive purposes), and also to the public interest. IETF should not support this effort. Keith From: triad at df.lth.se (Linus Walleij) Date: Sat Dec 6 21:57:32 2003 Subject: Registration of MIME media type Application/EDI-Tradacoms In-Reply-To: <001101c3ace6$12870540$60eb3444@nash01.tn.comcast.net> References: <001101c3ace6$12870540$60eb3444@nash01.tn.comcast.net> Message-ID: <1070744239.16581.56.camel@felicia> m?n 2003-11-17 klockan 09.37 skrev Kyle Meadors: > MIME subtype name: IETF Tree - EDI-Tradacoms (...) > Published specification: Refer to RFC 1767 First, MIME transport types are lowercase as in "edi-tradacoms" Obviously there is some difference between "edi-tradacoms" and what is already in RFC 1767. If you want a registration in the IETF tree, then write an amendment RFC as well, or the registration will be ambiguous. If this is only in use by your company, consider using the vnd. namespace. Linus Walleij