Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4V6d1B09731 for ietf-xml-mime-bks; Thu, 30 May 2002 23:39:01 -0700 (PDT) Received: from smtp-relay-1.adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V6d1g09727; Thu, 30 May 2002 23:39:01 -0700 (PDT) Received: from inner-relay-2.corp.adobe.com (inner-relay-2 [153.32.1.52]) by smtp-relay-1.adobe.com (8.12.3/8.12.3) with ESMTP id g4V6erfF014074; Thu, 30 May 2002 23:40:53 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g4V6axBA015019; Thu, 30 May 2002 23:36:59 -0700 (PDT) Received: from masinter ([130.248.182.2]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id GWYQGO00.FXA; Thu, 30 May 2002 23:38:48 -0700 From: "Larry Masinter" To: "'Dan Kohn'" , "'Larry Masinter'" , Cc: Subject: RE: dangers of application/xml Date: Thu, 30 May 2002 23:39:12 -0700 Message-ID: <004501c2086d$e576a290$6ace8642@masinter> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm happy with your rewrite of my rewrite of your rewrite of our paragraph, labeled "DAN'S SUGGESTION" in Dan Kohn's message of Thursday, May 30, 2002 11:22 PM. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4V6LoB06923 for ietf-xml-mime-bks; Thu, 30 May 2002 23:21:50 -0700 (PDT) Received: from kabul.ad.skymv.com ([66.120.210.133]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4V6Lgg06850; Thu, 30 May 2002 23:21:42 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: dangers of application/xml MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 May 2002 23:21:37 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dangers of application/xml Thread-Index: AcIIUggqB+FtnhyBQluv3Ws91VSW6AAFGF/A From: "Dan Kohn" To: "Larry Masinter" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4V6Lgg06851 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Larry, I find the first paragraph confusing in respect to certain XML datatypes, such as application/beep+xml. This kind of content is almost always expected to be found within a BEEP transaction. However, it does have meaning in other contexts. If found in the wild, the MIME label would at least let you know that you're looking at part of a beep transaction, and may be useful for analysis, archiving, or evaluating profiles. In particular (as specified in Section 6.4 of RFC 3080) there are two additional restrictions made on this kind of content beyond regular XML rules. You seem to favor that there should only be MIME types for discrete content that is regularly handled over multiple transports, such as image/svg+xml or application/calendar+xml. However, a MIME type that is registered but not used does no harm that I can see. So, I would place the bias in the other direction, that new datatypes (including protocol fragments) SHOULD be assigned a MIME type unless they have no meaning outside their original context. In particular, I think the emphasis of this sentence is backwards: "In cases where the choice of encoding of data may be limited to using a specific XML structure, the use of MIME labeling itself should be avoided if possible." It also repeats the sentiment of the previous paragraph. Finally, "never be recommended" at the end is much more clear as "should not be used", since this document is the one doing the recommending. CURRENT DRAFT (section 4.11 of ) says: o XML media types. Some protocols have protocol elements that are MIME bodies, and allow MIME labeling. In cases where a MIME label is used to identify a protocol element the MIME labeling policies defined in RFC 3023 [5] should be followed and an XML declaration should be present. Consistent with RFC 3023, protocol elements should be exchanged using the "application/xml" media type instead of the "text/xml" media type. However, as discussed in RFC 3023, "application/xml" may not be appropriate in all cases, and a new media type may be needed; if so, the new media type should be registered with the IANA. LARRY'S SUGGESTION: Using MIME to label XML content applies where XML entities are expected to be stand-alone, largely interpreted without reference to the context in which they appear. By contrast a piece of XML in a protocol element is often intimately bound to the protocol context in which it appears, and in particular might be directly derived from/input to protocol state-machine implementations, with consequently limited scope for interpretation. This document makes the following recommendations: In cases where the choice of encoding of data may be limited to using a specific XML structure, the use of MIME labeling itself should be avoided if possible. If MIME labeling is needed, then the advice of RFC 3023 applies. In particular, if the XML represents a new language or document type, a new MIME media type should be registered, for the reasons in RFC 3023 sections 7 and A.1. In situations where XML is used to encode generic structured data (e.g., a document-oriented application that involves combining XML with a stylesheet), "application/xml" may be used. Because of issues involving display behavior and default charsets, "text/xml" should never be recommended. DAN'S SUGGESTION: XML media types. A piece of XML in a protocol element is sometimes intrinsically bound to the protocol context in which it appears, and in particular might be directly derived from and/or input to protocol state-machine implementations. In cases where the XML content has no relevant meaning outside it's original protocol context, there is no reason to register a MIME type. When it is possible that XML content can be interpreted outside of its original context (such as when that XML content is being stored in a filesystem or tunneled over another protocol), then a MIME type should be registered to specify the specific format for the data and to provide a hint as to how it might be processed. If MIME labeling is needed, then the advice of RFC 3023 applies. In particular, if the XML represents a new language or document type, a new MIME media type should be registered, for the reasons in RFC 3023 sections 7 and A.1. In situations where XML is used to encode generic structured data (e.g., a document-oriented application that involves combining XML with a stylesheet), "application/xml" may be used. Because of issues involving display behavior and default charsets, "text/xml" should not be used. - dan -- Dan Kohn Essays announced on -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Thursday, May 30, 2002 20:20 To: ietf-xml-use@imc.org Subject: dangers of application/xml Here's an attempted rewrite Using MIME to label XML content applies where XML entities are expected to be stand-alone, largely interpreted without reference to the context in which they appear. By contrast a piece of XML in a protocol element is often intimately bound to the protocol context in which it appears, and in particular might be directly derived from/input to protocol state-machine implementations, with consequently limited scope for interpretation. This document makes the following recommendations: In cases where the choice of encoding of data may be limited to using a specific XML structure, the use of MIME labeling itself should be avoided if possible. If MIME labeling is needed, then the advice of RFC 3023 applies. In particular, if the XML represents a new language or document type, a new MIME media type should be registered, for the reasons in RFC 3023 sections 7 and A.1. In situations where XML is used to encode generic structured data (e.g., a document-oriented application that involves combining XML with a stylesheet), "application/xml" may be used. Because of issues involving display behavior and default charsets, "text/xml" should never be recommended. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OJMRd24637 for ietf-xml-mime-bks; Fri, 24 May 2002 12:22:27 -0700 (PDT) Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OJMQL24633 for ; Fri, 24 May 2002 12:22:26 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffprop@mail.proper.com Message-Id: Date: Fri, 24 May 2002 12:22:16 -0700 To: ietf-xml-mime@imc.org From: Joseph Reagle Subject: Re: Draft registration for application/xenc+xml Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Received: from aeon.w3.org (cave.ne.client2.attbi.com [66.30.12.33]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OFIgL17148 for ; Fri, 24 May 2002 08:18:42 -0700 (PDT) Received: by aeon.w3.org (Postfix, from userid 1000) id F2D9B859F4; Fri, 24 May 2002 11:18:37 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Joseph Reagle Reply-To: reagle@w3.org Organization: W3C To: ietf-xml-mime@imc.org, ian@w3.org Subject: Re: Draft registration for application/xenc+xml Date: Fri, 24 May 2002 11:18:37 -0400 X-Mailer: KMail [version 1.3.2] Cc: xml-encryption@w3.org, www-tag@w3.org References: <20020522222618.57C8285A94@aeon.w3.org> In-Reply-To: <20020522222618.57C8285A94@aeon.w3.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020524151837.F2D9B859F4@aeon.w3.org> On Wednesday 22 May 2002 18:26, Joseph Reagle wrote: > @@ Should we include a redundant type parameter of the encrypted > object? @@ I realized after I sent this that there is another issue that merits consideration. I borrowed text [1] from the rdf application and it seems fairly sensible but begs the question as to whether a document that has an element encrypted should have its media type changed. I would argue "no" (and this issue is being discussed by the W3C TAG [2]). But absent TAG resolution, is anyone opposed to text that states "However, the application/xenc+xml type name MUST only be used for data objects in which the root element is from the XENC namespace." Also, Ian, in [3] what does it mean that the registration should be part of the REC? That I should have an appendix in the spec with a copy of my request? (seems odd...) [1] http://lists.w3.org/Archives/Public/xml-encryption/2002May/att-0040/01-draft-reagle-xenc-mediatype-00.txt Additional Information: Magic number(s): none Although no byte sequences can be counted on to consistently identify XENC documents, they will have the sequence http://www.w3.org/2001/04/xmlenc# to identify the XENC namespace. This will usually be towards the top of the document, but may occur further down if parts of the XML document are being encrypted. [2] http://www.w3.org/2001/tag/ilist#mixedNamespaceMeaning-13 [3] http://www.w3.org/2001/tag/2002/0129-mime -- Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ W3C XML Encryption Chair http://www.w3.org/Encryption/2001/ Received: by above.proper.com (8.11.6/8.11.3) id g4OId8O23717 for ietf-xml-mime-bks; Fri, 24 May 2002 11:39:08 -0700 (PDT) Received: from aeon.w3.org (cave.ne.client2.attbi.com [66.30.12.33]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OId7L23713 for ; Fri, 24 May 2002 11:39:07 -0700 (PDT) Received: by aeon.w3.org (Postfix, from userid 1000) id 6CA0D859F4; Fri, 24 May 2002 14:39:04 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Joseph Reagle Reply-To: reagle@w3.org Organization: W3C To: Tim Bray Subject: Re: Draft registration for application/xenc+xml Date: Fri, 24 May 2002 14:39:04 -0400 X-Mailer: KMail [version 1.3.2] Cc: ietf-xml-mime@imc.org, xml-encryption@w3.org, www-tag@w3.org References: <20020522222618.57C8285A94@aeon.w3.org> <20020524151837.F2D9B859F4@aeon.w3.org> <3CEE688F.6050008@textuality.com> In-Reply-To: <3CEE688F.6050008@textuality.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020524183904.6CA0D859F4@aeon.w3.org> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday 24 May 2002 12:21, Tim Bray wrote: > > Also, Ian, in [3] what does it mean that the registration should be > > part of the REC? That I should have an appendix in the spec with a copy > > of my request? (seems odd...) > > I think that's the idea. Why odd? -Tim Not odd, but .... Is the expectation that there will also be an orthogonal ietf-draft -> RFC or registration request document? If so, wouldn't a reference to it be sufficient? (If we're using the registration process, should the TR be dependent on that process: can't leave CR until the registration is issued? Or can the WG commit to the registration but the documents don't need to be inter-dependent? Or will a section within a W3C specification be an adequate referent for the IANA registry? -- Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ W3C XML Encryption Chair http://www.w3.org/Encryption/2001/ Received: by above.proper.com (8.11.6/8.11.3) id g4OIWFg23592 for ietf-xml-mime-bks; Fri, 24 May 2002 11:32:15 -0700 (PDT) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OIWDL23587 for ; Fri, 24 May 2002 11:32:14 -0700 (PDT) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id OAA28908; Fri, 24 May 2002 14:40:53 -0400 Date: Fri, 24 May 2002 14:40:53 -0400 From: Mark Baker To: Joseph Reagle Cc: ietf-xml-mime@imc.org, ian@w3.org, xml-encryption@w3.org, www-tag@w3.org Subject: Re: Draft registration for application/xenc+xml Message-ID: <20020524144053.H19846@www.markbaker.ca> References: <20020522222618.57C8285A94@aeon.w3.org> <20020524151837.F2D9B859F4@aeon.w3.org> <20020524132221.D19846@www.markbaker.ca> <20020524181359.4D017859F4@aeon.w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20020524181359.4D017859F4@aeon.w3.org>; from reagle@w3.org on Fri, May 24, 2002 at 02:13:59PM -0400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Joseph, On Fri, May 24, 2002 at 02:13:59PM -0400, Joseph Reagle wrote: > Hi Mark, the XML Encryption syntax has the capacity to represent this > information. (And it is OPTIONAL, so if we have it in both places, it would > be odd to have it be required in the mediatype.) If you encrypt a PNG, the > resulting instance might look like: Sorry, I forgot about 'MimeType'. That changes things. I agree that the parameter is redundant, and therefore I'd recommend against it. I've just had a quick look at the spec, but I need to spend more time thinking about MimeType & Type, to make sure that it handles this properly. For example, I would think that a recommendation to not guess the value of MimeType, but to reuse the media type (if known) of the content, would be a good idea. More later, if I find anything requiring comment. Thanks. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@acm.org http://www.markbaker.ca http://www.idokorro.com Received: by above.proper.com (8.11.6/8.11.3) id g4OIEJb23163 for ietf-xml-mime-bks; Fri, 24 May 2002 11:14:19 -0700 (PDT) Received: from aeon.w3.org (cave.ne.client2.attbi.com [66.30.12.33]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OIEHL23157 for ; Fri, 24 May 2002 11:14:17 -0700 (PDT) Received: by aeon.w3.org (Postfix, from userid 1000) id 4D017859F4; Fri, 24 May 2002 14:13:59 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Joseph Reagle Reply-To: reagle@w3.org Organization: W3C To: Mark Baker Subject: Re: Draft registration for application/xenc+xml Date: Fri, 24 May 2002 14:13:59 -0400 X-Mailer: KMail [version 1.3.2] Cc: ietf-xml-mime@imc.org, ian@w3.org, xml-encryption@w3.org, www-tag@w3.org References: <20020522222618.57C8285A94@aeon.w3.org> <20020524151837.F2D9B859F4@aeon.w3.org> <20020524132221.D19846@www.markbaker.ca> In-Reply-To: <20020524132221.D19846@www.markbaker.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020524181359.4D017859F4@aeon.w3.org> Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Friday 24 May 2002 13:22, Mark Baker wrote: > On Fri, May 24, 2002 at 11:18:37AM -0400, Joseph Reagle wrote: > > On Wednesday 22 May 2002 18:26, Joseph Reagle wrote: > > > @@ Should we include a redundant type parameter of the encrypted > > > object? @@ > > I believe that this is more than a good idea, it's a necessity. > Moreover, it should also be a required parameter. Hi Mark, the XML Encryption syntax has the capacity to represent this information. (And it is OPTIONAL, so if we have it in both places, it would be odd to have it be required in the mediatype.) If you encrypt a PNG, the resulting instance might look like: A23B45C56 > The reason I say this is because an xml-enc intermediary may want to > encrypt some HTML that arrived as text/plain. If it just gets > encrypted, relabelled as application/xenc+xml, and then forwarded on, > the fact that it was "text/plain" is now lost (it's not redundant), > and the next intermediary to process it must guess the encapsulated > content type. My bias when presented with a situation where some characteristic of some resource can be described in multiple/orthogonal ways is not to be redundant, but have it represented as close to its "home." Consequently, I figure if you know enough about xenc to care about what's in there, read the xenc instance. However, I ask the question because I'm not sure how people architect their dispatching such that if an agent receives a xenc instance: 1. it calls the xenc processor and hands the instance to it, 2. but instead of waiting for the xenc processor to return the decrypted object and type, it can prep for the expected type while it's waiting. I don't think this likely, and I'd rather not be redundant, but I honestly don't know. Received: by above.proper.com (8.11.6/8.11.3) id g4OHDhR22055 for ietf-xml-mime-bks; Fri, 24 May 2002 10:13:43 -0700 (PDT) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OHDgL22050 for ; Fri, 24 May 2002 10:13:42 -0700 (PDT) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id NAA27923; Fri, 24 May 2002 13:22:21 -0400 Date: Fri, 24 May 2002 13:22:21 -0400 From: Mark Baker To: Joseph Reagle Cc: ietf-xml-mime@imc.org, ian@w3.org, xml-encryption@w3.org, www-tag@w3.org Subject: Re: Draft registration for application/xenc+xml Message-ID: <20020524132221.D19846@www.markbaker.ca> References: <20020522222618.57C8285A94@aeon.w3.org> <20020524151837.F2D9B859F4@aeon.w3.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20020524151837.F2D9B859F4@aeon.w3.org>; from reagle@w3.org on Fri, May 24, 2002 at 11:18:37AM -0400 Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, May 24, 2002 at 11:18:37AM -0400, Joseph Reagle wrote: > On Wednesday 22 May 2002 18:26, Joseph Reagle wrote: > > @@ Should we include a redundant type parameter of the encrypted > > object? @@ I believe that this is more than a good idea, it's a necessity. Moreover, it should also be a required parameter. The reason I say this is because an xml-enc intermediary may want to encrypt some HTML that arrived as text/plain. If it just gets encrypted, relabelled as application/xenc+xml, and then forwarded on, the fact that it was "text/plain" is now lost (it's not redundant), and the next intermediary to process it must guess the encapsulated content type. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@acm.org http://www.markbaker.ca http://www.idokorro.com Received: by above.proper.com (8.11.6/8.11.3) id g4OGLdv19575 for ietf-xml-mime-bks; Fri, 24 May 2002 09:21:39 -0700 (PDT) Received: from mail.dev.antarcti.ca (gt.antarcti.ca [209.17.183.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OGLbL19567 for ; Fri, 24 May 2002 09:21:37 -0700 (PDT) Received: from textuality.com (dev1.dev.antarcti.ca [10.1.1.8]) by mail.dev.antarcti.ca (Postfix) with ESMTP id ACE12102DA; Fri, 24 May 2002 09:21:26 -0700 (PDT) Message-ID: <3CEE688F.6050008@textuality.com> Date: Fri, 24 May 2002 09:21:35 -0700 From: Tim Bray User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: reagle@w3.org Cc: ietf-xml-mime@imc.org, ian@w3.org, xml-encryption@w3.org, www-tag@w3.org Subject: Re: Draft registration for application/xenc+xml References: <20020522222618.57C8285A94@aeon.w3.org> <20020524151837.F2D9B859F4@aeon.w3.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-xml-mime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Joseph Reagle wrote: > But absent TAG > resolution, is anyone opposed to text that states "However, the > application/xenc+xml type name MUST only be used for data objects in which > the root element is from the XENC namespace." Seems sensible to me. > > Also, Ian, in [3] what does it mean that the registration should be part of > the REC? That I should have an appendix in the spec with a copy of my > request? (seems odd...) I think that's the idea. Why odd? -Tim