Joseph Reagle | 7 Aug 2002 20:38
Picon
Favicon

draft-reagle-xenc-mediatype-01.txt


Please update [1] with the attached draft-reagle-xenc-mediatype-01.txt . 
(The draft is only a reference to the media type registration, in 
accordance with [2], found in the actual specification.)

[1] http://www.ietf.org/internet-drafts/draft-reagle-xenc-mediatype-00.txt
[2] http://www.w3.org/2002/06/registering-mediatype.html

-- 
* I will be on holiday the week of August 12th; I will try to return any 
calls or emails received the following week. 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle <at> w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

                                                              J. Reagle
Internet-Draft                                              W3C/LCS/MIT
Expires: February 2003                                      August 2002

              application/xenc+xml Media Type Registration
                    draft-reagle-xenc-mediatype-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with all
   provisions of Section 10 of RFC2026.
(Continue reading)

Joseph Reagle | 8 Aug 2002 21:00
Picon
Favicon

Re: draft-reagle-xenc-mediatype-01.txt


[I'm going to separate this thread into three replies: (1) the requirements 
on me for advancing the W3C document, (2) questions associated with the 
policy, and (3) comments on the actual registration -- which I'll also cc 
to the appropriate lists.]

(3) The actual registration

On Thursday 08 August 2002 01:58 am, ned.freed <at> mrochek.com wrote:
> > As for the registration itself at
> > 
http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/#sec-MediaType-Registration
> >
> > I think there are several problems; most of which are of the
> > form that the template makes references that aren't specific
> > enough. For example, the 'charset' parameter is defined
> > by reference to RFC 3023, but RFC 3023 allows for a wide
> > range of usage of the 'charset' parameter, and it's not
> > clear which this specification means; t
>
> The charset reference isn't to RFC 3023, it is to the charset parameter
> defined in RFC 3023 for the application/xml media type. I believe that's
> specific enough; if it isn't surely that would mean that the definition
> for application/xml isn't specific enough either...

As Ned and Martin point out, the intent is to express the fact that 
"application/xenc+xml" is XML, and consequently shares the same charset and 
encoding semantics/processing as that defined in RFC 3023.

> > the 'encoding considerations'
(Continue reading)

Larry Masinter | 9 Aug 2002 00:07
Picon
Favicon

RE: draft-reagle-xenc-mediatype-01.txt


Let me try to be more specific.

> > The charset reference isn't to RFC 3023, it is to the charset
parameter
> > defined in RFC 3023 for the application/xml media type. I  believe
that's
> > specific enough; if it isn't surely that would mean that the
definition
> > for application/xml isn't specific enough either...
> 
> As Ned and Martin point out, the intent is to express the fact that 
> "application/xenc+xml" is XML, and consequently shares the same
charset and 
> encoding semantics/processing as that defined in RFC 3023.
> 

What it actually says is:

# Optional parameters: charset

#  Same as charset parameter of application/xml as
#  specified in RFC 3023 [XML-MT] or the most recent
#  specification that supersedes it.

I admit I was a little confused on this one, and misread
what it said. However, I don't understand
"or the most recent specification that supersedes it",
though, since a specification may supercede RFC 3023
but not be appropriate for a reference to a particular
(Continue reading)

Martin Duerst | 9 Aug 2002 05:27
Picon
Favicon

Re: draft-reagle-xenc-mediatype-01.txt


At 15:00 02/08/08 -0400, Joseph Reagle wrote:
>The specification says, "This media-type is only used for documents in which
>the EncryptedData and EncryptedKey element types appear as the root element
>of the XML document." I'm not sure how to be much more clear than that?

Well, change "EncryptedData and EncryptedKey" to
"EncryptedData or EncryptedKey". I haven't seen
an XML doc yet with two root elements.

Regards,    Martin.

Martin Duerst | 9 Aug 2002 05:14
Picon
Favicon

Re: draft-reagle-xenc-mediatype-01.txt


At 15:00 02/08/08 -0400, Joseph Reagle wrote:
>As Ned and Martin point out, the intent is to express the fact that
>"application/xenc+xml" is XML, and consequently shares the same charset and
>encoding semantics/processing as that defined in RFC 3023.

Well, what the spec currently writes is okay, but what
you just write above is not:

The intent is to say that application/xenc+xml shares the same
charset behaviour as application/xml defined in RFC 3023.
(text/xml behaves differently)

Regards,   Martin.

Martin Duerst | 9 Aug 2002 05:45
Picon
Favicon

RE: draft-reagle-xenc-mediatype-01.txt


At 15:07 02/08/08 -0700, Larry Masinter wrote:
>What it actually says is:
>
># Optional parameters: charset
>
>#  Same as charset parameter of application/xml as
>#  specified in RFC 3023 [XML-MT] or the most recent
>#  specification that supersedes it.
>
>I admit I was a little confused on this one, and misread
>what it said. However, I don't understand
>"or the most recent specification that supersedes it",
>though, since a specification may supercede RFC 3023
>but not be appropriate for a reference to a particular
>section. None of the other references (to XML, DES,
>HTTP, MIME, etc.) have this qualification (that they
>refer to either the current version or anything that
>supersedes it.)

I agree with Larry that a moving target is a bad idea.
At W3C, we use (mostly) dated references, don't we :-).

>I would prefer if the reference were more specific about
>what was the "same": the same syntax, the same set of
>allowable values, the same recommendation for use of
>particular values, the same interpretation of defaults,
>or all of the above. Assuming you mean 'all of the above',
>you could be more explicit:
>
(Continue reading)

Joseph Reagle | 19 Aug 2002 20:47
Picon
Favicon

Re: draft-reagle-xenc-mediatype-01.txt


On Thursday 08 August 2002 06:07 pm, Larry Masinter wrote:
> # Optional parameters: charset
> #  Same as charset parameter of application/xml as
> #  specified in RFC 3023 [XML-MT] or the most recent
> #  specification that supersedes it.
>
> I admit I was a little confused on this one, and misread
> what it said. However, I don't understand
> "or the most recent specification that supersedes it",
> though, since a specification may supercede RFC 3023
> but not be appropriate for a reference to a particular
> section. 

I'm happy to eliminate that text as I oppose those sort of references in 
general. In this case, I was merely following what I could see the rdf 
folks doing for a similar type of registration:
  http://www.aaronsw.com/2002/rdf-mediatype.html

Joseph Reagle | 19 Aug 2002 21:58
Picon
Favicon

Re: draft-reagle-xenc-mediatype-01.txt


[Resulting text:
  http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/
  $Revision: 1.237 $ on $Date: 2002/08/19 19:57:54 $ GMT
]

On Thursday 08 August 2002 06:07 pm, Larry Masinter wrote:
> I'm a little concerned about allowing arbitrary charset
> values for the entire application/xml+enc body, though,
> when any encrypted data are always UTF-8 encoded.

The encrypted data are always UTF-8 encoded when the data being encrypted is 
XML, but may not be for other media type. Additionally, this doesn't apply 
to the EncryptedData XML document itself (e.g., the KeyName example given 
by Martin). We have no additional constraints on an EncryptedData or 
EncryptedKey instance. It's generic XML.

> Again, I would prefer if the reference were more explicit
> about exactly was 'the same'.

This bit now reads, "Published specification:  [XML-Encryption] " (It's kind 
of a odd for a spec to have references to itself, but so be it...)

> You might even note that because
> encrypted data is encoded in base64 that encrypted data
> may have different encoding requirements than the data
> it replaces.

Yep, that's why the introduction says, "Additionally it allows applications 
cognizant of this media-type (even if they are not XML Encryption 
(Continue reading)

Martin Duerst | 20 Aug 2002 04:19
Picon
Favicon

Re: draft-reagle-xenc-mediatype-01.txt


Hello Aaron, dear RDF Core WG,

On ietf-types <at> iana.org and some related list, we were just looking
at http://www.w3.org/TR/xmlenc-core/#sec-MediaType which containes
some instances of text like this:

    Same as ... of application/xml as specified in RFC 3023[XML-MT]
    or the most recent specification that supercedes it.

There seemed to be general agreement that a moving target is
not a good idea.

Josef Reagle told us that he got that text from:
http://www.aaronsw.com/2002/rdf-mediatype.html

I wanted to tell you that you may want to fix this.

Regards,   Martin.

At 14:47 02/08/19 -0400, Joseph Reagle wrote:
>On Thursday 08 August 2002 06:07 pm, Larry Masinter wrote:
> > # Optional parameters: charset
> > #  Same as charset parameter of application/xml as
> > #  specified in RFC 3023 [XML-MT] or the most recent
> > #  specification that supersedes it.
> >
> > I admit I was a little confused on this one, and misread
> > what it said. However, I don't understand
> > "or the most recent specification that supersedes it",
(Continue reading)

Aaron Swartz | 20 Aug 2002 18:51
Gravatar

Re: draft-reagle-xenc-mediatype-01.txt


To: Martin Duerst <duerst <at> w3.org>
Cc: <ned.freed <at> mrochek.com>, "Larry Masinter" <LMM <at> acm.org>, 
reagle <at> w3.org,
    <ietf-xml-mime <at> imc.org>, <ietf-types <at> iana.org>, 
<w3c-policy <at> apps.ietf.org>,
    w3c-rdfcore-wg <at> w3.org, Graham Klyne <GK <at> NineByNine.org>

On Monday, August 19, 2002, at 09:19  PM, Martin Duerst wrote:
>  There seemed to be general agreement that a moving target is not a
>  good idea.

I was working on advice from Graham Klyne:

http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Apr/0001.html

If the IETF community is in agreement it should go, then I'll remove it.
--

-- 
Aaron Swartz [http://www.aaronsw.com] I am large, I contain multitudes.


Gmane