Subject: RE: dangers of application/xml
From: "Larry Masinter" <[email-masked]>
To: "'Dan Kohn'" <[email-masked]>, "'Larry Masinter'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Thu, 30 May 2002 23:39:12 -0700
List-Id: <ietf-xml-mime.imc.org>

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.

content-class: urn:content-classes:message
Subject: RE: dangers of application/xml
Date: Thu, 30 May 2002 23:21:37 -0700
From: "Dan Kohn" <[email-masked]>
To: "Larry Masinter" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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
<http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guideline
s-03.txt>) 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 <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: Larry Masinter [mailto:[email-masked]] 
Sent: Thursday, May 30, 2002 20:20
To: [email-masked]
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.

Date: Fri, 24 May 2002 12:22:16 -0700
To: [email-masked]
From: Joseph Reagle <[email-masked]>
Subject: Re: Draft registration for application/xenc+xml
Sender: [email-masked]

From: Joseph Reagle <[email-masked]>
Reply-To: [email-masked]
Organization: W3C
To: [email-masked], [email-masked]
Subject: Re: Draft registration for application/xenc+xml
Date: Fri, 24 May 2002 11:18:37 -0400
Cc: [email-masked], [email-masked]

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:[email-masked]
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

From: Joseph Reagle <[email-masked]>
Reply-To: [email-masked]
Organization: W3C
To: Tim Bray <[email-masked]>
Subject: Re: Draft registration for application/xenc+xml
Date: Fri, 24 May 2002 14:39:04 -0400
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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:[email-masked]
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Date: Fri, 24 May 2002 14:40:53 -0400
From: Mark Baker <[email-masked]>
To: Joseph Reagle <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Draft registration for application/xenc+xml
Sender: [email-masked]

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.               [email-masked]
http://www.markbaker.ca        http://www.idokorro.com

From: Joseph Reagle <[email-masked]>
Reply-To: [email-masked]
Organization: W3C
To: Mark Baker <[email-masked]>
Subject: Re: Draft registration for application/xenc+xml
Date: Fri, 24 May 2002 14:13:59 -0400
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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:

  <?xml version='1.0'?> 
  <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
   MimeType='image/png'>
    <CipherData>
      <CipherValue>A23B45C56</CipherValue>
    </CipherData>
  </EncryptedData>

> 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.

Date: Fri, 24 May 2002 13:22:21 -0400
From: Mark Baker <[email-masked]>
To: Joseph Reagle <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Draft registration for application/xenc+xml
Sender: [email-masked]

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.               [email-masked]
http://www.markbaker.ca        http://www.idokorro.com

Date: Fri, 24 May 2002 09:21:35 -0700
From: Tim Bray <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Draft registration for application/xenc+xml
Sender: [email-masked]

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