Subject: Re: CORRECTION: Please review ietf-draft of SMIL media-type registration
From: Philipp Hoschka <[email-masked]>
To: Kari Pihkala <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Tue, 27 Aug 2002 16:02:07 +0200
List-Id: <ietf-xml-mime.imc.org>

Kari,

good catches !

See inline for more

Kari Pihkala wrote:
> 
> Hi,
> 
> I noticed some inconsistencies with the SMIL namespaces in the
> draft. In section 4:
> 
> All SMIL 2.0 files must also include a declaration of the SMIL 2.0
>    namespace.  This should appear shortly after the string "<smil", and
>    should read 'xmlns="http://www.w3.org/2001/SMIL20/PR/Language"'.

Fixed this to use
http://www.w3.org/2001/SMIL20/Language

as namespace.
 
> However, a different namespace in the end of section 5:
> 
> An example use of this parameter as part of a HTTP GET transaction
>    would be:
> 
>         Accept: application/smil+xml;
>            profile="http://www.w3.org/2001/SMIL20/REC/HostLanguage"

Removed the REC part.

The namespace should be different, I think, since this is the way 
that a client informs a server that it supports SMIL basic.

I'm not sure that people actually use the following URI to
identify SMIL basic, however
http://www.w3.org/2001/SMIL20/REC/HostLanguage

or that anyone uses the "accept" header at all - I'll send a
seperate message to the www-smil list on that.

> Also, either of these namespaces match the one in SMIL 2.0 spec
> (http://www.w3.org/TR/2001/REC-smil20-20010807/smil20-profile.html):
> 13.3.2 SMIL 2.0 Language Conformance
> 
> 5. A document must declare a default namespace for its elements with an
> xmlns attribute on the smil root element with its identifier URI:
> <smil xmlns="http://www.w3.org/2001/SMIL20/Language">
>    ...
> </smil>
> 
> You may want to check these...
> 
>  - Kari
...

Date: Thu, 22 Aug 2002 14:42:55 +0200
From: Philipp Hoschka <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Please review ietf-draft of SMIL media-type registration
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------3E057BDBA78E6604561A8263
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This email serves to instantiate the two week discussion 
period on "[email-masked]" of the ietf-draft describing
the SMIL media-type registration. You can find the draft at
http://www.ietf.org/internet-drafts/draft-hoschka-smil-media-type-10.txt

The expected course of advancement for this specification is:
1. I have notified one of the Application area directors (Ned Freed)
2. Request publication as an Informational RFC as specified:
  ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt
3. Ensure IANA is aware of the publication and posts the registration as 
specified:
  ftp://ftp.isi.edu/in-notes/rfc2048.txt

The changes in this specification since the last version discussed on 
"[email-masked]" include:
1. Registration of application/xml+smil in addition to application/smil
2. Addition of optional "profile" parameter
3. Addition of paragraph describing how to recognize SMIL files by
   looking into the file.

Thank you.

-- 

-Philipp Hoschka
--------------3E057BDBA78E6604561A8263
Content-Type: text/plain; charset=iso-8859-1;
 name="draft-reagle-xenc-mediatype-00.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="draft-reagle-xenc-mediatype-00.txt"

--------------3E057BDBA78E6604561A8263--

Date: Tue, 20 Aug 2002 11:51:00 -0500
Subject: Re: draft-reagle-xenc-mediatype-01.txt
From: Aaron Swartz <[email-masked]>
To: [email-masked]
Sender: [email-masked]

To: Martin Duerst <[email-masked]>
Cc: <[email-masked]>, "Larry Masinter" <[email-masked]>, 
[email-masked],
    <[email-masked]>, <[email-masked]>, 
<[email-masked]>,
    [email-masked], Graham Klyne <[email-masked]>

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.

Date: Tue, 20 Aug 2002 11:19:58 +0900
To: [email-masked], [email-masked]
From: Martin Duerst <[email-masked]>
Subject: Re: draft-reagle-xenc-mediatype-01.txt
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, [email-masked], "Larry Masinter" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hello Aaron, dear RDF Core WG,

On [email-masked] 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",
> > 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
>

From: Joseph Reagle <[email-masked]>
Reply-To: [email-masked]
Organization: W3C
To: "Larry Masinter" <[email-masked]>, <[email-masked]>, "'Martin Duerst'" <[email-masked]>
Subject: Re: draft-reagle-xenc-mediatype-01.txt
Date: Mon, 19 Aug 2002 15:58:25 -0400
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'XML Encryption'" <[email-masked]>
Sender: [email-masked]

[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 
implementations) to note that the media type of the decrypted (original) 
object might be a type other than XML." (Maybe this doesn't belong in the 
introduction, but I'm not sure of a better place?)

> > references [2] in the same way I have done. I haven't been able to
> > find any example of a  "MIME type threat analysis".
>
> Encrypted content may be unsafe content.

Can you point me to any other registration that uses similar text I can 
borrow? (Instead of crafting green text myself). Until then, I've added a 
section 6.5:

[[
 6.5 Unsafe Content
XML Encryption can be used to obscure, via encryption, content that 
applications (e.g., firewalls, virus detectors, etc.) consider unsafe 
(e.g., executable code, viruses, etc.). Consequently, such applications 
must consider encrypted content to be as unsafe as the unsafest content 
transported in its application context. Consequently, such applications may 
choose to (1) disallow such content, (2) require access to the decrypted 
form for inspection, or (3) ensure that arbitrary content can be safely 
handled by receiving applications.
]]

> I think you might just put it inline:
>
>   Published specification:
>        This document. The application/xenc+xml media type
>        may be used with XML documents in which the EncryptedData
>        and EncryptedKey element types, in the XML Encryption
>        namespace, appear as the root element of the XML document.

There was text like this in the "magic number" section which is now further 
augmented.

From: Joseph Reagle <[email-masked]>
Reply-To: [email-masked]
Organization: W3C
To: "Larry Masinter" <[email-masked]>, <[email-masked]>, "'Martin Duerst'" <[email-masked]>
Subject: Re: draft-reagle-xenc-mediatype-01.txt
Date: Mon, 19 Aug 2002 14:47:37 -0400
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'XML Encryption'" <[email-masked]>
Sender: [email-masked]

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

From: simonstl <[email-masked]>
To: [email-masked]
Subject: Happy Assumption
Date: Fri, 16 Aug 2002 13:58:34 +0800
Sender: [email-masked]

--N68H18de891T4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

------------------  Virus Warning Message (on the network)

Found virus WORM_KLEZ.H in file Track
The uncleanable file is deleted.

---------------------------------------------------------

--N68H18de891T4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;

<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:UR73a38d1Yn height=3D0 width=3D0>
</iframe>
<FONT></FONT></BODY></HTML>

--N68H18de891T4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

------------------  Virus Warning Message (on the network)

Track is removed from here because it contains a virus.

---------------------------------------------------------
--N68H18de891T4

--N68H18de891T4
Content-Type: application/octet-stream;
	name=rfc2915.txt
Content-ID: <UR73a38d1Yn>
Content-Transfer-Encoding: base64

--N68H18de891T4--

Date: Fri, 09 Aug 2002 12:27:56 +0900
To: [email-masked]
From: Martin Duerst <[email-masked]>
Subject: Re: draft-reagle-xenc-mediatype-01.txt
Cc: [email-masked], [email-masked], [email-masked], XML Encryption <[email-masked]>
Sender: [email-masked]

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.

Date: Fri, 09 Aug 2002 12:45:14 +0900
To: "Larry Masinter" <[email-masked]>, <[email-masked]>
From: Martin Duerst <[email-masked]>
Subject: RE: draft-reagle-xenc-mediatype-01.txt
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'XML Encryption'" <[email-masked]>
Sender: [email-masked]

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:
>
> >  Optional parameters: charset
> >
> >   The allowable and recommended values for, and interpretation
> >   of the charset parameter are identical to those given
> >   for 'application/xml' in section 3.2 of RFC 3023.

I'm not sure this is a good idea. It may lead to
questions such as 'and what about the default value,
is that different',... In other words, trying to list
up all the aspects in which the charset parameter for
application/xenc+xml is the same as that for application/xml
is a futile exercise; not listing any aspects and therefore
making clear that it's everything makes things clearer
and easier, I guess.

>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.
>Is it expected that the decryption algorithm do transcoding?
>Shouldn't the behavior of the processor with non-UTF-8
>encoded xml+enc bodies be discussed?

As far as I remember it, encryption does something like
the following:
1) Convert the necessary pieces to UTF-8 (from the encoding
    the document is in)
2) Encrypt the UTF-8 bytes
3) 'Textify' the result of the encryption by using base64

The decryption algorithm has to reverse these steps,
including step 1).

Allowing arbitrary charset values for application/xml+enc
is no problem. First, these values will apply to the
non-encrypted pieces of the document. (I can obviously
have something like <ds:KeyName>鈴木太郎</ds:KeyName>)
Second, once the encrypted part is textified as base64,
that text can still be encoded in us-ascii (which would
be covered by UTF-8) or in ebcdic or utf-16,...

So what I think may make sense is to add something like:

Note: The character encoding denoted by the "charset"
parameter is the character encoding of the resulting XML
document after encoding.

> > > > the 'encoding considerations'
> >
>http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-MediaType-Regi
>stration
>
>Again, I would prefer if the reference were more explicit
>about exactly was 'the same'.

Again, in general I would disagree here.

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

Good point.

># Published specification: this document.

I think that 'published specification: this document' is quite
dangerous. Assume somebody (that may be IANA) copies the registration
only for their own purposes. Then the reference is lost.

Regards,    Martin.

Date: Fri, 09 Aug 2002 12:14:13 +0900
To: [email-masked]
From: Martin Duerst <[email-masked]>
Subject: Re: draft-reagle-xenc-mediatype-01.txt
Cc: [email-masked], [email-masked], [email-masked], XML Encryption <[email-masked]>
Sender: [email-masked]

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.

From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "'Martin Duerst'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'XML Encryption'" <[email-masked]>
Subject: RE: draft-reagle-xenc-mediatype-01.txt
Date: Thu, 8 Aug 2002 15:07:18 -0700
Keywords: backed-up
Importance: Normal
Sender: [email-masked]

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

>  Optional parameters: charset
>
>   The allowable and recommended values for, and interpretation
>   of the charset parameter are identical to those given
>   for 'application/xml' in section 3.2 of RFC 3023.

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.
Is it expected that the decryption algorithm do transcoding?
Shouldn't the behavior of the processor with non-UTF-8
encoded xml+enc bodies be discussed?

> > > the 'encoding considerations'
>
http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-MediaType-Regi
stration

Again, I would prefer if the reference were more explicit
about exactly was 'the same'. 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.

> > > the "Security Considerations" section contains a vague
> > > reference ('many of those described in') to a section
> > > of the document that doesn't actually do a threat analysis
> > > of the MIME type.
> 
> Ned and Larry, can you indicate what you mean by this? I 
> looked at other encrypted data formats included S/MIME and PGP; on
this 
> point I relied upon the example of application/pgp-encrypted [1] which

> references [2] in the same way I have done. I haven't been able to
find any 
> example of a  "MIME type threat analysis".

Encrypted content may be unsafe content. XML with encrypted data
might be a way of transmitting virus or trojan containing media
in a way that would not be detectible by ordinary virus scanning
filters on firewalls, for example. So application/xml+enc is
as unsafe as the unsafest content it can transport, and yet
transporting the data in a way that makes it immune to most of
the virus-detection and protection mechanisms that companies employ.

An analysis of this threat and the implementation techniques
necessary to mitigate the threat should be part of the description.

> > > The 'public specification' reference isn't
> 
> Do you mean, "published specification" -- I'm not sure what you are 
> referring to.

Yes, the problem is that the reference inside the template
doesn't point specifically enough. The 'template' itself says

# Published specification: this document.

If you are trying to find what the media type means, you follow
the link from the template. What part of 'this document'
is the published specification? Section 8.1 (which contains
the words you quote) is labeled 'Introduction', rather than
'Definition', so I skipped it when I was scanning for where
application/xml+enc is defined.

I think you might just put it inline:

  Published specification:
       This document. The application/xenc+xml media type
       may be used with XML documents in which the EncryptedData
       and EncryptedKey element types, in the XML Encryption
       namespace, appear as the root element of the XML document.

From: Joseph Reagle <[email-masked]>
Reply-To: [email-masked]
Organization: W3C
To: [email-masked], Larry Masinter <[email-masked]>, Martin Duerst <[email-masked]>
Subject: Re: draft-reagle-xenc-mediatype-01.txt
Date: Thu, 8 Aug 2002 15:00:28 -0400
Cc: [email-masked], [email-masked], [email-masked], XML Encryption <[email-masked]>
Sender: [email-masked]

[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, [email-masked] 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'
> > are clearly incorrect ("Same as charset parameter"?!?),
> The encoding text looks like a cut and paste error to me; I suspect the
> intent was to refer to the encoding considerations for application/xml
> defined in RFC 3023.

Correct, this was a cut and paste error and now remedied in the Editors' 
draft. Thanks!
    
http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/#sec-MediaType-Registration
$Revision: 1.234 $ on $Date: 2002/08/08 18:34:24 $ GMT

> > the "Security Considerations" section contains a vague
> > reference ('many of those described in') to a section
> > of the document that doesn't actually do a threat analysis
> > of the MIME type.

Ned and Larry, can you indicate what you mean by this? I looked at other 
encrypted data formats included S/MIME and PGP; on  this point I relied 
upon the example of application/pgp-encrypted [1] which references [2] in 
the same way I have done. I haven't been able to find any example of a  
"MIME type threat analysis".

[1] http://www.rfc-editor.org/rfc/rfc3156.txt
[2] http://www.ietf.org/rfc/rfc2440.txt

> > The 'public specification' reference isn't

Do you mean, "published specification" -- I'm not sure what you are 
referring to.

> > clear which byte streams can legitimately be called
> > 'application/xenc+xml' (do you mean 'an XML body that
> > conforms to the Encryption Syntax specified in section 3
> > of this document', perhaps)...

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?

-- 
* 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:[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: [email-masked]
Subject: draft-reagle-xenc-mediatype-01.txt
Date: Wed, 7 Aug 2002 14:38:57 -0400
Cc: XML Encryption <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

--------------Boundary-00=_X4LH5O32C6FFVC80HIH4
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 8bit

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

--------------Boundary-00=_X4LH5O32C6FFVC80HIH4
Content-Type: text/plain;
  charset="us-ascii";
  name="draft-reagle-xenc-mediatype-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="draft-reagle-xenc-mediatype-01.txt"

                                                              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.

   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 as 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/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract

   This document describes a media type (application/xenc+xml) for use
   with the XML Encryption specification.

Table of Contents

    1. Discussion of this Document
    2. Registration
    3. References
    4. Author's Address
    5. Full Copyright Statement
     _________________________________________________________________

1. Discussion of this Document

   Please send comments to [email-masked]. To subscribe, send a
   message with the body 'subscribe' to [email-masked]. The
   mailing list is publicly archived at
   http://lists.w3.org/Archives/Public/xml-encryption/ .

Reagle, J.                 Expires October 2002                 [Page 1] 

Internet-Draft           XML Encryption Media-Type              June 2002 

2. Registration

   Please see the XML Encryption Media Type specified in [XENC].

4. References

   XENC
          XML Encryption Syntax and Processing. D. Eastlake, and J.
          Reagle. W3C Candidate Recommendation, 2002.
          http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/

5. Authors' Address

   Joseph M. Reagle Jr., W3C
   Massachusetts Institute of Technology
   Laboratory for Computer Science
   NE43-358, 200 Technology Square
   Cambridge, MA 02139
   Phone: + 1.617.258.7621
   Email: [email-masked]

6. Full Copyright

   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.

--------------Boundary-00=_X4LH5O32C6FFVC80HIH4--