Subject: Re: Request for comments for Media Type registration ofapplication/ccxml+xml
From: Al Gilman <[email-masked]>
To: <[email-masked]>
Date: Sat, 31 Jul 2004 13:50:44 -0400
List-Id: <ietf-xml-mime.imc.org>

Copy of
http://www.w3.org/mid/p06110400bd2d389cc364@%5B10.0.1.2%5D
resent for administrative reasons.   See archive copy above for other
recipients.  - Al

At 3:03 PM +0900 7/28/04, Martin Duerst wrote:
>At 13:05 04/07/27 -0700, RJ Auburn wrote:
>
>>On 07/21/2004 22:03, "Larry Masinter" <[email-masked]> wrote:
>>
>>>  These comments are as much about the general "IETF MIME type
>>>  registration from W3C recommendation" as they are about this
>>>  particular registration:
>>
>>
>>Martin: Would you be the person to handle/address the general issues?
>
>Yes. For everybody's information, RJ is following the procedure laid
>out at http://www.w3.org/2002/06/registering-mediatype.html#Planned.
>Because he is the first to do so, this is a very good case to see
>where we have to tweak that description. I have already made two
>additions:
>1) Added a sentence "Make sure that this part of the specification
>    is readable on its own, without the context of the specification."
>    [for further details, a good example is probably better than a
>     lot of explanations]
>2) Added a sentence "To make it easier for your WG to track comments
>    on the Media Type section, you may cross-post the comments list
>    for your specification."
>    [I want to leave this to the group for the moment. They have to
>     show that they addressed comments to the IESG, so having that
>     documented in a last call table may have advantages and
>     disadvantages.]
>
>Also, I'm planning to add some pointers to examples to the above
>description, once we have them. That should make it easier for
>others to do this.
>
>>  > Your translation from HTML to ASCII left out line breaks
>>>  before heading lines, which made your template hard
>>>  to read.
>>
>>If needed I can resubmit a nicer looking version. Let me know...
>
>I guess that can wait for the next time you send something anyway,
>but I hope this will be soon.
>
>>  >> Published specification:
>>>>
>>>>  This media type registration is for CCXML documents as
>>>>  described by this specification.
>>>
>>>  I'm not 100% sure if this is necessary, but I'd expect
>>>  if the template were to appear elsewhere to see
>>>  a bibliographic citation, e.g.,
>>>
>>>  "Voice Browser Call Control: CCXML Version 1.0", W3C
>>>  Working Draft, 30 April 2004, W3C, <http://www.w3.org/TR/ccxml/>
>>>
>>>  Is "this specification" (or the whole specification) precise
>>>  enough?  In some other cases, a single W3C recommendation defines
>>>  many different data types. Perhaps it would be useful to
>>>  say, somewhere, e.g., that the MIME type refers to XML bodies that
>>>  conform to the DTD/Schema referenced in Appendix B and C and
>>>  interpreted by the rules in the cited specification.
>>
>>
>>Pointing at the schema/dtd sections seems reasonable.  How is this for text:
>>
>>Published specification:
>>     This media type registration is for XML bodies that
>>     conform to the DTD/Schema referenced in Appendix B and C and
>>     interpreted by the rules this specification
>
>'this specification' -> 'of this specification'
>
>>  >> Person & email address to contact for further information:
>>>>
>>>>  RJ Auburn, <[email-masked]>.
>>>
>>>  Should there be a W3C contact as well?
>>
>>
>>Dave/Max/Martin: Thoughts?
>
>Adding the name of a staff contact or so might be a good idea.
>
>>  >> Intended usage:
>>>>
>>>>  COMMON
>>>>  Author/Change controller:
>>>>
>>>>  The CCXML specification is a work product of the World Wide Web
>>>  Consortium's
>>>>  Voice Browser Working Group. The W3C has change control over these
>>>>  specifications.
>>>
>>>  Or perhaps the W3C contact address should be listed here.
>>
>>Dave/Max/Martin: Thoughts?
>
>The W3C is 'on the Web', not at a particular physical location.
>This kind of wording has been used in some previous registrations,
>and should be okay.

Actually, Martin, the W3C should come up with something better.  This is
a detail of the "life after Rec[ommendation status is achieved]" that I am
not aware we have laid out adequately.

There is a slight problem because the W3C has studiously avoided being
a legal entity which could be identified in standard X.500 terms.

But if we take the specification

http://lists.w3.org/Archives/Member/w3c-wai-pf/2004JulSep/0075.html

The document identifies a contact address of

mailto:[email-masked]

This is standard practice, viz:

<quote cite=
"http://www.w3.org/Consortium/Contact">
Do you have a technical comment?
W3C technical reports include email addresses where     readers 
should send technical comments.
</quote>

The Consortium has also assiduously avoided promising to answer 
questions about its
utterances, other than that one may post 'comments' in the above 
manner.  Clearly a 'comment'
alleging that there is an inconsistency in the provisions of a 
specification, if read and found
to be accurate, may result in something being added to the errata for 
a document.

I would suggest that the 'comments to' email address be included in 
the contact information
provided in a MIME type registration request.

As far as identifying The Consortium it should suffice to use the URI 
http://www.w3.org/ as
identification in this context.

It would be helpful, but probably not required by the IETF 
pro-formas, to also allude to the
process for change control by a reference to the W3C Process Document 
identified as:

http://www.w3.org/Consortium/Process/

Al

>Regards,    Martin.

Date: Wed, 28 Jul 2004 14:54:40 +0900
To: RJ Auburn <[email-masked]>, Chris Lilley <[email-masked]>, Larry Masinter <[email-masked]>
From: Martin Duerst <[email-masked]>
Subject: Re: Request for comments for Media Type registration ofapplication/ccxml+xml
Cc: "'Dan Connolly'" <[email-masked]>, [email-masked], Dave Raggett <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 14:37 04/07/27 -0700, RJ Auburn wrote:
>Chris:
>
>Comments and replies are inline. Let me know if there are any other issues:
>
>
>On 07/22/2004 11:05, "Chris Lilley" <[email-masked]> wrote:
> > I agree that this sort of context, although obvious when the W3C
> > document as a whole is studies, is fairly opaque when a single appendix
> > is extracted and sent as an email message.
> >
> > Prepending the 'Abstract' of the specification, and giving a link to the
> > full specification, would be helpful.
>
>
>Sorry. I should have done this.
>Martin: any chance we could update the w3c page with some examples of what
>should be sent to this list? I think it might be helpful to have some
>pointers to good example requests.

Yes. For that, we first have to have good examples. I'm looking forward
to use your next mail to this list as such an example.

> >>> Published specification:
> >>>
> >>> This media type registration is for CCXML documents as
> >>> described by this specification.
> >
> > 'This specification' should be a link to the main page of the document,
> > even if that is a link to itself for a short document, and inline URIs
> > should be indicated in the ascii text version by a numbered link [1]
> >
> > [1] http://example.org/like/this
>
>This section now reads:
>
>Published specification:
>
>     This media type registration is for XML bodies that
>     conform to the DTD/Schema referenced in Appendix B and C and
>     interpreted by the rules of the CCXML specification [1].
>
>       [1] http://www.w3.org/tr/ccxml/

I personally think that this kind of '[1]' citation is a bit
of overkill. If you get that from a text conversion on the W3C
Web site, feel free to use it. But I think something like

     This media type registration is for XML bodies that
     conform to the DTD/Schema referenced in Appendix B and C and
     interpreted by the rules of the CCXML specification at
     http://www.w3.org/tr/ccxml/.

is more readable, and more popular in plain text formats such
as email.

>Ok, this is what it will look like now:
>
>Magic number(s):
>
>There is no single initial octet sequence that is always present in CCXML
>documents. This media type is expected to be handled by an XML processor, as
>indicated by "+xml". XML processors may detect CCXML by its namespace URI,
>http://www.w3.org/2002/09/ccxml
>
>Is this ok with folks?

Okay with me.

Regards,    Martin.

Date: Wed, 28 Jul 2004 15:03:56 +0900
To: RJ Auburn <[email-masked]>, Larry Masinter <[email-masked]>
From: Martin Duerst <[email-masked]>
Subject: Re: Request for comments for Media Type registration ofapplication/ccxml+xml
Cc: "'Dan Connolly'" <[email-masked]>, Dave Raggett <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 13:05 04/07/27 -0700, RJ Auburn wrote:

>On 07/21/2004 22:03, "Larry Masinter" <[email-masked]> wrote:
>
> > These comments are as much about the general "IETF MIME type
> > registration from W3C recommendation" as they are about this
> > particular registration:
>
>
>Martin: Would you be the person to handle/address the general issues?

Yes. For everybody's information, RJ is following the procedure laid
out at http://www.w3.org/2002/06/registering-mediatype.html#Planned.
Because he is the first to do so, this is a very good case to see
where we have to tweak that description. I have already made two
additions:
1) Added a sentence "Make sure that this part of the specification
    is readable on its own, without the context of the specification."
    [for further details, a good example is probably better than a
     lot of explanations]
2) Added a sentence "To make it easier for your WG to track comments
    on the Media Type section, you may cross-post the comments list
    for your specification."
    [I want to leave this to the group for the moment. They have to
     show that they addressed comments to the IESG, so having that
     documented in a last call table may have advantages and
     disadvantages.]

Also, I'm planning to add some pointers to examples to the above
description, once we have them. That should make it easier for
others to do this.

> > Your translation from HTML to ASCII left out line breaks
> > before heading lines, which made your template hard
> > to read.
>
>If needed I can resubmit a nicer looking version. Let me know...

I guess that can wait for the next time you send something anyway,
but I hope this will be soon.

> >> Published specification:
> >>
> >> This media type registration is for CCXML documents as
> >> described by this specification.
> >
> > I'm not 100% sure if this is necessary, but I'd expect
> > if the template were to appear elsewhere to see
> > a bibliographic citation, e.g.,
> >
> > "Voice Browser Call Control: CCXML Version 1.0", W3C
> > Working Draft, 30 April 2004, W3C, <http://www.w3.org/TR/ccxml/>
> >
> > Is "this specification" (or the whole specification) precise
> > enough?  In some other cases, a single W3C recommendation defines
> > many different data types. Perhaps it would be useful to
> > say, somewhere, e.g., that the MIME type refers to XML bodies that
> > conform to the DTD/Schema referenced in Appendix B and C and
> > interpreted by the rules in the cited specification.
>
>
>Pointing at the schema/dtd sections seems reasonable.  How is this for text:
>
>Published specification:
>     This media type registration is for XML bodies that
>     conform to the DTD/Schema referenced in Appendix B and C and
>     interpreted by the rules this specification

'this specification' -> 'of this specification'

> >> Person & email address to contact for further information:
> >>
> >> RJ Auburn, <[email-masked]>.
> >
> > Should there be a W3C contact as well?
>
>
>Dave/Max/Martin: Thoughts?

Adding the name of a staff contact or so might be a good idea.

> >> Intended usage:
> >>
> >> COMMON
> >> Author/Change controller:
> >>
> >> The CCXML specification is a work product of the World Wide Web
> > Consortium's
> >> Voice Browser Working Group. The W3C has change control over these
> >> specifications.
> >
> > Or perhaps the W3C contact address should be listed here.
>
>Dave/Max/Martin: Thoughts?

The W3C is 'on the Web', not at a particular physical location.
This kind of wording has been used in some previous registrations,
and should be okay.

Regards,    Martin.

Date: Tue, 27 Jul 2004 10:12:14 +0900
From: MURATA Makoto <[email-masked]>
To: [email-masked]
Subject: Fw: Re: Fw: Revising RFC 3023
Sender: [email-masked]

Another mail about XML versions.

Cheers,
Makoto

Forwarded by MURATA Makoto <[email-masked]>
----------------------- Original Message -----------------------
From:    [email-masked]
To:      MURATA Makoto <[email-masked]>
Date:    Mon, 26 Jul 2004 21:04:24 -0400
Subject: Re: Fw: Revising RFC 3023
----

Makoto:  thank you so much for circulating this.  I think these issues 
would indeed benefit from some attention.  I thought I should clarify for 
those outside of IBM that the note from which you quote below was 
originally written last Feb.   In particular, the sections on SOAP in 
particular predate the recent discussions in the XMLP workgroup of XML 1.1 
handling in SOAP.    Also, none of this is specifically a comment on his 
recently circulated I-D. 

Regarding SOAP, what you should get out of the attached is merely that 
there are situations in which a W3C Recommendation may for good reason 
need to specify the use of particular versions of XML, including in 
particular XML 1.0.  (As it happens, the XMLP workgroup is planning to 
make exactly such a specification for SOAP, in part because we feel that 
we cannot support XML 1.1 until XML Schema does.)  Otherwise, I stand 
behind both the suggestions for the W3C and for RFC 3023.  Thank you.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

MURATA Makoto <[email-masked]>
07/26/04 07:19 PM

        To:     [email-masked]
        cc:     [email-masked]
        Subject:        Fw: Revising RFC 3023

Forwarded by MURATA Makoto <[email-masked]>
----------------------- Original Message -----------------------
From:    MURATA Makoto <[email-masked]>
To:      [email-masked]
Date:    Sun, 25 Jul 2004 22:43:07 +0900
Subject: Revising RFC 3023
----

I am forwarding an e-mail from Noah Mendelsohn.  It contains some
suggestions I got from Noah in private discussion at IBM.  I have his
permission to circulate publicly.

Cheers,

MURATA Makoto
--------------------------------------------
Murata Makoto writes:

>> It is true that RFC 3023 does not reference to XML 1.1, although I
>> do not see anything specific to XML 1.0 (with the exception of
>> security concerns caused by C0 control functions)..

The references I found in 3023 are:

"The World Wide Web Consortium has issued Extensible Markup Language
(XML) 1.0 (Second Edition)[XML].  " "Published specification:
Extensible Markup Language (XML) 1.0 (Second Edition)[XML]."

and more specifically all the examples which show:

Content-type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>

and so on.  I now see that all of this may have just been intended as
the then-latest forms, but I read them as specific instructions for
use of xml 1.0 as the proper form of application/xml.  So, at the very
least, I think it would be helpful to be more explicit in future
replacements or updates to 3023.

>> I plan to reference to XML 1.1 as well as XML 1.0 in the next I-D,
>> which is expected to supsersede RFC 3023.

I'm torn about this.  In the specific case of SOAP, our recommendation
says that implementations of our HTTP bindings MUST be capable of
sending and receiving in the media-type "application/soap+xml", which
we normatively base on 3023 and application/xml.  In making this
statement, I doubt that most members of the working group realized
that they might have been introducing an open-ended need to conform to
all future versions of XML, including those that would allow
previously-illegal control character content.  Maybe if we'd known
such an XML 1.1 was coming we would have and should have put in such a
requirement to support both: my point is just that I don't think we
did so consciously.

I have openned a discussion of all this on the distApp mailing list
[1], and will in a minute send an update pointing out the tie-in to
RFC 3023.  I will cc: you on that update.  distApp is a public mailing
list, and you are most welcome to join in.

For what it's worth, SOAP puts a tremendous emphasis on
interoperability, so saying that two conforming implemenations of this
binding can disagree about what's legal in the preferred form of
messages is at least a bit troubling.  The original design point was:
if you conform, you can communicate.  Even if 3023 is to support any
version of XML, we in SOAP may be able to fix things with a
clarification to our recommendation.  It so happens that we already
allow use of any other media type, it's just that we make clear that
application/soap+xml is the lingua franca.  Use something else and it
will only work if the recipient agrees.  I suspect we'll wind up
saying: "application/xml with xml version 1.0 is the lingua franca,
you can use other media types or application/soap+xml with later
versions of XML, but only if the recipient supports them."

The control character business is a bigger mess for us I think, as we
have a quite strong rule that the constraints on SOAP envelopes are
the same everywhere, and they are basically what you'd expect from
Infoset (and implicitly XML 1.0).  Note that such envelopes are by
definition synthetic Infosets.  XML 1.1 suggests that, regardless of
how you serialize the message on each hop, there is a question as to
whether in the abstract the new control characters are allowed in the
envelope infosets.  If so, then such messages cannot transit hops
implemented with already deployed software, and that's very troubling
to me.

>> If you have any comments about how these two specs should be
>> referenced, please let me know.  I even think that there should be a
>> W3C guideline about references to XML 1.0 and XML 1.1.  Does the XML
>> Core WG have some recommendations?

I'm not sure I have a carefully considered opinion, but what about the
following as a starting point for discussion?

Very Rough Draft of Proposed W3C policy:

"The publication of XML 1.1 highlights the fact that evolved versions
of XML may change both the serialized form of an XML document and the
content representable in such a document.  In the case of XML 1.1, for
example, certain control characters disallowed by XML 1.0 were added
to the Char production.  Accordingly, W3C recommends that:

* Every recommendation or other publication that makes normative
reference to XML as a serialized document format should make clear
which versions of XML it supports, and in particular whether it allows
for support of potential variants to be published in the future.

* When calling for serialization of data into an XML document, such
recommendations SHOULD appeal to the conventions of the supported
versions of XML regarding proper use of the XML declaration (for
example, the XML 1.1 recommendation suggests use of version="1.1" only
for those documents which would not be correctly represented as
version="1.0".)

* Recommendations should similarly clarify any dependencies on
particular versions of XML regarding the abstract content of data
modeled as XML.  For example, a recommendation based on the Infoset,
XPath data model, DOM, SAX, etc.  SHOULD indicate whether the control
characters introduced by XML 1.1 are allowed in element content,
SHOULD indicate whether potential future changes to XML constructs
such (e.g. a purely hypothetical future change to the set of legal XML
name characters) would be supported, and so on.  "

In the case of future versions of RFC 3023, I think the most
appropriate course might be to say:

"application/xml is to be used with any W3C Recommendation-level
version of XML as identified in the version specification of the XML
declaration.  When no such declaration is present, XML 1.0 is assumed.
In all examples herein where a specific version such as version="1.0"
is shown, it is understood that other versions may also be used,
providing the content does indeed conform to the specified version of
the XML Recommendation.

Specifications and recommendations based on or referring to this RFC
SHOULD indicate any limitations on the particular versions of XML to
be used.  For example, a particular specification might indicate:
"content MUST be represented using media-type application/xml, and the
document must either (a) carry an xml declaration specifying
version="1.0" or (b) omit the xml declaration, in which case per the
XML recommendation the version defaults to 1.0"

Does that seem like a reasonable start? 

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0006.html

--------------------- Original Message Ends --------------------

-- 
MURATA Makoto <[email-masked]>

--------------------- Original Message Ends --------------------

--------------------- Original Message Ends --------------------

Date: Sun, 25 Jul 2004 22:43:07 +0900
From: MURATA Makoto <[email-masked]>
To: [email-masked]
Subject: Revising RFC 3023
Sender: [email-masked]

I am forwarding an e-mail from Noah Mendelsohn.  It contains some
suggestions I got from Noah in private discussion at IBM.  I have his
permission to circulate publicly.

Cheers,

MURATA Makoto
--------------------------------------------
Murata Makoto writes:

>> It is true that RFC 3023 does not reference to XML 1.1, although I
>> do not see anything specific to XML 1.0 (with the exception of
>> security concerns caused by C0 control functions)..

The references I found in 3023 are:

"The World Wide Web Consortium has issued Extensible Markup Language
(XML) 1.0 (Second Edition)[XML].  " "Published specification:
Extensible Markup Language (XML) 1.0 (Second Edition)[XML]."

and more specifically all the examples which show:

Content-type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>

and so on.  I now see that all of this may have just been intended as
the then-latest forms, but I read them as specific instructions for
use of xml 1.0 as the proper form of application/xml.  So, at the very
least, I think it would be helpful to be more explicit in future
replacements or updates to 3023.

>> I plan to reference to XML 1.1 as well as XML 1.0 in the next I-D,
>> which is expected to supsersede RFC 3023.

I'm torn about this.  In the specific case of SOAP, our recommendation
says that implementations of our HTTP bindings MUST be capable of
sending and receiving in the media-type "application/soap+xml", which
we normatively base on 3023 and application/xml.  In making this
statement, I doubt that most members of the working group realized
that they might have been introducing an open-ended need to conform to
all future versions of XML, including those that would allow
previously-illegal control character content.  Maybe if we'd known
such an XML 1.1 was coming we would have and should have put in such a
requirement to support both: my point is just that I don't think we
did so consciously.

I have openned a discussion of all this on the distApp mailing list
[1], and will in a minute send an update pointing out the tie-in to
RFC 3023.  I will cc: you on that update.  distApp is a public mailing
list, and you are most welcome to join in.

For what it's worth, SOAP puts a tremendous emphasis on
interoperability, so saying that two conforming implemenations of this
binding can disagree about what's legal in the preferred form of
messages is at least a bit troubling.  The original design point was:
if you conform, you can communicate.  Even if 3023 is to support any
version of XML, we in SOAP may be able to fix things with a
clarification to our recommendation.  It so happens that we already
allow use of any other media type, it's just that we make clear that
application/soap+xml is the lingua franca.  Use something else and it
will only work if the recipient agrees.  I suspect we'll wind up
saying: "application/xml with xml version 1.0 is the lingua franca,
you can use other media types or application/soap+xml with later
versions of XML, but only if the recipient supports them."

The control character business is a bigger mess for us I think, as we
have a quite strong rule that the constraints on SOAP envelopes are
the same everywhere, and they are basically what you'd expect from
Infoset (and implicitly XML 1.0).  Note that such envelopes are by
definition synthetic Infosets.  XML 1.1 suggests that, regardless of
how you serialize the message on each hop, there is a question as to
whether in the abstract the new control characters are allowed in the
envelope infosets.  If so, then such messages cannot transit hops
implemented with already deployed software, and that's very troubling
to me.

>> If you have any comments about how these two specs should be
>> referenced, please let me know.  I even think that there should be a
>> W3C guideline about references to XML 1.0 and XML 1.1.  Does the XML
>> Core WG have some recommendations?

I'm not sure I have a carefully considered opinion, but what about the
following as a starting point for discussion?

Very Rough Draft of Proposed W3C policy:

"The publication of XML 1.1 highlights the fact that evolved versions
of XML may change both the serialized form of an XML document and the
content representable in such a document.  In the case of XML 1.1, for
example, certain control characters disallowed by XML 1.0 were added
to the Char production.  Accordingly, W3C recommends that:

* Every recommendation or other publication that makes normative
reference to XML as a serialized document format should make clear
which versions of XML it supports, and in particular whether it allows
for support of potential variants to be published in the future.

* When calling for serialization of data into an XML document, such
recommendations SHOULD appeal to the conventions of the supported
versions of XML regarding proper use of the XML declaration (for
example, the XML 1.1 recommendation suggests use of version="1.1" only
for those documents which would not be correctly represented as
version="1.0".)

* Recommendations should similarly clarify any dependencies on
particular versions of XML regarding the abstract content of data
modeled as XML.  For example, a recommendation based on the Infoset,
XPath data model, DOM, SAX, etc.  SHOULD indicate whether the control
characters introduced by XML 1.1 are allowed in element content,
SHOULD indicate whether potential future changes to XML constructs
such (e.g. a purely hypothetical future change to the set of legal XML
name characters) would be supported, and so on.  "

In the case of future versions of RFC 3023, I think the most
appropriate course might be to say:

"application/xml is to be used with any W3C Recommendation-level
version of XML as identified in the version specification of the XML
declaration.  When no such declaration is present, XML 1.0 is assumed.
In all examples herein where a specific version such as version="1.0"
is shown, it is understood that other versions may also be used,
providing the content does indeed conform to the specified version of
the XML Recommendation.

Specifications and recommendations based on or referring to this RFC
SHOULD indicate any limitations on the particular versions of XML to
be used.  For example, a particular specification might indicate:
"content MUST be represented using media-type application/xml, and the
document must either (a) carry an xml declaration specifying
version="1.0" or (b) omit the xml declaration, in which case per the
XML recommendation the version defaults to 1.0"

Does that seem like a reasonable start?  

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2004Feb/0006.html

--------------------- Original Message Ends --------------------

-- 
MURATA Makoto <[email-masked]>

Date: Sun, 25 Jul 2004 09:25:41 +0900
From: MURATA Makoto <[email-masked]>
To: [email-masked]
Subject: An I-D for text/xml, application/xml, etc.
Sender: [email-masked]

Based on the discussions in this mailing list and W3C TAG, an 
I-D for XML media types has been created.  Major changes from 
RFC 3023 are as follows:

   First, text/xml and text/xml-external-parsed-entity are deprecated.
   Second, XPointer ([XPointerFramework] and [XPointerElement]) has been
   added as fragment identifiers for "application/xml".  Third, [XBase]
   has been added as a mechanism for specifying base URIs.  Fourth, many
   references are updated.

http://www.ietf.org/internet-drafts/draft-murata-kohn-lilley-xml-00.txt

Comments welcome.

Cheers,

-- 
MURATA Makoto <[email-masked]>

Date: Thu, 22 Jul 2004 20:08:24 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Larry Masinter <[email-masked]>
Cc: [email-masked], "'Martin Duerst'" <[email-masked]>, "'Dan Connolly'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Request for comments for Media Type registration of application/ccxml+xml
Sender: [email-masked]

On Thursday, July 22, 2004, 7:03:48 AM, Larry wrote:

LM> Or perhaps the W3C contact address should be listed here.

One more comment.

>From the Status of this Document:

>> This document is for public review. Comments and discussion are
>> welcomed on the public mailing list < [email-masked] >. To
>> subscribe, send an email to <www-voice-request@w3. org> with the word
>> subscribe in the subject line (include the word unsubscribe if you
>> want to unsubscribe). The archive for the list is accessible on-line.

Since the review includes the appendix, perhaps review comments on the
registration appendix should also be sent to the above review address
and handled like other Last call comments?

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Date: Thu, 22 Jul 2004 20:05:32 +0200
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: Larry Masinter <[email-masked]>
Cc: [email-masked], "'Martin Duerst'" <[email-masked]>, "'Dan Connolly'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Request for comments for Media Type registration of application/ccxml+xml
Sender: [email-masked]

On Thursday, July 22, 2004, 7:03:48 AM, Larry wrote:

LM> These comments are as much about the general "IETF MIME type
LM> registration from W3C recommendation" as they are about this
LM> particular registration:

LM> -------------

LM> It might be helpful if the registration template explained
LM> that "ccxml" stood for "Call Control eXtensible Markup Language"
LM> for use in voice browser applications, and that the registration
LM> is in a document intended to become a W3C recommendation.

I agree that this sort of context, although obvious when the W3C
document as a whole is studies, is fairly opaque when a single appendix
is extracted and sent as an email message.

Prepending the 'Abstract' of the specification, and giving a link to the
full specification, would be helpful.

LM> I'm not sure this is necessary, but since we're getting
LM> W3C recommendations registering MIME types, I wondered
LM> if making the registration template just a little bit
LM> more explanatory would be useful.

Certainly.

LM> Your translation from HTML to ASCII left out line breaks
LM> before heading lines, which made your template hard
LM> to read.

LM> Specific comments:

>> this case, the security issues of RFC1738, section 6, should 
>> be considered.

LM> RFC 1738 has been superseded quite a while ago, by 2396.

When citing an RFC abcd, it is useful to do a Google search for
"Obsoletes: abcd" and "Updates: abcd" because RFCs do not have 'latest
version' URIs (or indeed canonical URIs at all).

>> Published specification:
>> 
>> This media type registration is for CCXML documents as 
>> described by this specification.

'This specification' should be a link to the main page of the document,
even if that is a link to itself for a short document, and inline URIs
should be indicated in the ascii text version by a numbered link [1]

[1] http://example.org/like/this

A conversion to text can be obtained for any W3C document by appending
,text to the URI (before any fragment) for example
http://www.w3.org/TR/ccxml/,text#ccxml-mime-definition
which is redirected to (watch out for line
wrapping):
http://cgi.w3.org/cgi-bin/html2txt?url=http://www.w3.org/TR/ccxml/#ccxml-mime-definition

LM> I'm not 100% sure if this is necessary, but I'd expect
LM> if the template were to appear elsewhere to see
LM> a bibliographic citation, e.g., 

LM> "Voice Browser Call Control: CCXML Version 1.0", W3C
LM> Working Draft, 30 April 2004, W3C, <http://www.w3.org/TR/ccxml/>

I agree.

LM> Is "this specification" (or the whole specification) precise
LM> enough?

Not when the appendix is transmitted separately, no.

LM>   In some other cases, a single W3C recommendation defines
LM> many different data types. Perhaps it would be useful to
LM> say, somewhere, e.g., that the MIME type refers to XML bodies that
LM> conform to the DTD/Schema referenced in Appendix B and C and
LM> interpreted by the rules in the cited specification.

>> Additional information:
>> Magic number(s):
>> 
>> There is no single initial octet sequence that is always 
>> present in CCXML documents.

LM> While this section is titled "Magic number", I think
LM> what we're seeing in MIME registrations for XML content
LM> is a description of how to recognize CCXML if it isn't
LM> labeled. It would be useful here to identify the namespace
LM> expected and the likely root XML element name(s).

Yes, I agrre that this is current good practice. The text in this
registration is fine, but it should add something like:

This media type is expected to be handled by an XML processor, as
indicated by "+xml". XML processors may detect ccXML by its namespace
URI, http://www.w3.org/2001/vxml

Hmm the revision to RFC 3023 should probably supply suggested
boilerplate for this and, indeed, perhaps a registration template with
the common items for all +xml types.

>> Person & email address to contact for further information:
>> 
>> RJ Auburn, <[email-masked]>.

LM> Should there be a W3C contact as well?

The person listed is the W3C Editor of the specification. The fact that
they are the document editor should be noted since its not apparent from
the appendix in isolation.

>> Intended usage:
>> 
>> COMMON
>> Author/Change controller:
>> 
>> The CCXML specification is a work product of the World Wide Web
LM> Consortium's
>> Voice Browser Working Group. The W3C has change control over these
>> specifications.

LM> Or perhaps the W3C contact address should be listed here.

LM> Larry

-- 
 Chris Lilley                    mailto:[email-masked]
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Date: Wed, 21 Jul 2004 22:03:48 -0700
From: Larry Masinter <[email-masked]>
Subject: RE: Request for comments for Media Type registration of application/ccxml+xml
To: [email-masked]
Cc: "'Martin Duerst'" <[email-masked]>, "'Dan Connolly'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

These comments are as much about the general "IETF MIME type
registration from W3C recommendation" as they are about this
particular registration:

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

It might be helpful if the registration template explained
that "ccxml" stood for "Call Control eXtensible Markup Language"
for use in voice browser applications, and that the registration
is in a document intended to become a W3C recommendation.

I'm not sure this is necessary, but since we're getting
W3C recommendations registering MIME types, I wondered
if making the registration template just a little bit
more explanatory would be useful.

Your translation from HTML to ASCII left out line breaks
before heading lines, which made your template hard
to read.

Specific comments:

> this case, the security issues of RFC1738, section 6, should 
> be considered.

RFC 1738 has been superseded quite a while ago, by 2396.

> In addition, because of the extensibility features for CCXML, it is
possible
> that "application/ccxml+xml" may describe content that has security
> implications beyond those described here. However, if the processor
follows
> only the normative semantics of this specification, this content will be
> ignored. Only in the case where the processor recognizes and processes the
> additional content, or where further processing of that content is
> dispatched to other processors, would security issues potentially arise.
And
> in that case, they would fall outside the domain of this registration
> document.

I don't think it's true that it falls outside the domain,
and the argument is just confusing. One major purpose of the
"security considerations" section is to help firewall
and security perimeter vendors decide what they need
to do when they see content marked with this type.

If receivers are likely to interpret extensions and the
extensions are likely to cause security problems if interpreted,
you should say so. If the document explains, in allowing for
extensions, how to avoid security problems, then say so.

> Interoperability considerations:
> 
> This specification describes processing semantics that dictate behavior
that
> must be followed when dealing with, among other things, unrecognized
> elements.
> 
> Because CCXML is extensible, conferment 

conformant?

> "application/ccxml+xml" processors
> can expect that content received is well-formed XML, but it cannot be
> guaranteed that the content is valid CCXML or that the processor will
> recognize all of the elements and attributes in the document.

I think the main purpose of "interoperability considerations" is
to talk about reasons why multiple implementations might not
interoperate.  I don't know if you have any of those, but
I don't think what you say here (that someone might send
non-conformant content labeled with this MIME type)
really fits. Are all conforming CCXML implementations guaranteed 
to be interoperable? If not, why not?

> Published specification:
> 
> This media type registration is for CCXML documents as 
> described by this specification.

I'm not 100% sure if this is necessary, but I'd expect
if the template were to appear elsewhere to see
a bibliographic citation, e.g., 

"Voice Browser Call Control: CCXML Version 1.0", W3C
Working Draft, 30 April 2004, W3C, <http://www.w3.org/TR/ccxml/>

Is "this specification" (or the whole specification) precise
enough?  In some other cases, a single W3C recommendation defines
many different data types. Perhaps it would be useful to
say, somewhere, e.g., that the MIME type refers to XML bodies that
conform to the DTD/Schema referenced in Appendix B and C and
interpreted by the rules in the cited specification.

> Additional information:
> Magic number(s):
> 
> There is no single initial octet sequence that is always 
> present in CCXML documents.

While this section is titled "Magic number", I think
what we're seeing in MIME registrations for XML content
is a description of how to recognize CCXML if it isn't
labeled. It would be useful here to identify the namespace
expected and the likely root XML element name(s).

> Person & email address to contact for further information:
> 
> RJ Auburn, <[email-masked]>.

Should there be a W3C contact as well?

> Intended usage:
> 
> COMMON
> Author/Change controller:
> 
> The CCXML specification is a work product of the World Wide Web
Consortium's
> Voice Browser Working Group. The W3C has change control over these
> specifications.

Or perhaps the W3C contact address should be listed here.

Larry
-- 
http://larry.masinter.net

To: [email-masked]
Subject: Submission: "The 'application/ssml+xml' Media Type" : ietf-xml-mime
From: Max Froumentin <[email-masked]>
Organization: W3C
Date: Wed, 21 Jul 2004 17:35:53 +0200
Sender: [email-masked]

--=-=-=

Resending through spamtrap

--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

Date: Sat, 17 Jul 2004 11:23:14 -0700
To: Max Froumentin <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Submission: "The 'application/ssml+xml' Media Type" :
 ietf-xml-mime
Status: O
Content-Length: 13729

>  >From owner-ietf-xml-mime Mon Jul 12 04:35:35 2004
>Received: from homer.w3.org (homer.w3.org [18.29.0.30])
>	by above.proper.com (8.12.11/8.12.9) with ESMTP id i6CBZ54p013996
>	for <[email-masked]>; Mon, 12 Jul 2004 04:35:35 -0700 (PDT)
>	(envelope-from [email-masked])
>Received: from jetlag (homer.w3.org [18.29.0.30])
>	by homer.w3.org (Postfix) with ESMTP id 90C1C4F16F;
>	Mon, 12 Jul 2004 07:35:05 -0400 (EDT)
>To: [email-masked]
>Cc: [email-masked], [email-masked], [email-masked]
>Subject: Submission: "The 'application/ssml+xml' Media Type"Sender: 
>Max Froumentin <[email-masked]>
>From: Max Froumentin <[email-masked]>
>Organization: W3C
>Date: Mon, 12 Jul 2004 13:35:10 +0200
>Message-ID: <[email-masked]>
>User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux)
>MIME-Version: 1.0
>Content-Type: multipart/mixed; boundary="=-=-="
>
>--=-=-=
>
>Dear editor,
>
>Please find below the updated submission for a media type registation
>"ssml+xml". This document updates an expired submission at [2].
>
>The document was earlier sent to ietf-types [1] and was revised for
>this submission.
>
>
>[1] 
>http://eikenes.alvestrand.no/pipermail/ietf-types/2003-December/000134.html
>[2] http://www.mail-archive.com/[email-masked]/msg12940.html
>
>Max Froumentin
>W3C
>
>
>--=-=-=
>Content-Disposition: attachment;
>   filename=draft-froumentin-ssml-media-reg.txt
>
>
>
>Network Working Group                                      M. Froumentin
>Internet-Draft                                             July 12, 2004
>Expires: January 10, 2005
>
>
>                  The 'application/ssml+xml' Media Type
>                  draft-froumentin-ssml-media-reg-01.txt
>
>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.
>
>    This Internet-Draft will expire on January 10, 2005.
>
>Copyright Notice
>
>    Copyright (C) The Internet Society (2004).  All Rights Reserved.
>
>Abstract
>
>    This document defines the 'application/ssml+xml' media type for the
>    Speech Synthesis based markup language.
>
>
>
>
>
>
>
>
>
>
>
>
>
>Froumentin              Expires January 10, 2005                [Page 1]
>
>Internet-Draft    The 'application/ssml+xml' Media Type        July 2004
>
>
>Table of Contents
>
>    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
>    2.   Registration of MIME media type application/ssml+xml . . . . . 4
>      2.1  MIME media type name . . . . . . . . . . . . . . . . . . . . 4
>      2.2  MIME subtype name  . . . . . . . . . . . . . . . . . . . . . 4
>      2.3  Required parameters  . . . . . . . . . . . . . . . . . . . . 4
>      2.4  Optional parameters  . . . . . . . . . . . . . . . . . . . . 4
>        2.4.1  charset  . . . . . . . . . . . . . . . . . . . . . . . . 4
>      2.5  Encoding considerations  . . . . . . . . . . . . . . . . . . 4
>      2.6  Fragment identifiers . . . . . . . . . . . . . . . . . . . . 4
>      2.7  Security Considerations  . . . . . . . . . . . . . . . . . . 4
>      2.8  Interoperability considerations  . . . . . . . . . . . . . . 5
>      2.9  Published specification  . . . . . . . . . . . . . . . . . . 5
>      2.10   Applications which use this media type . . . . . . . . . . 5
>      2.11   Additional information . . . . . . . . . . . . . . . . . . 5
>        2.11.1   Magic number(s)  . . . . . . . . . . . . . . . . . . . 5
>        2.11.2   File extension(s)  . . . . . . . . . . . . . . . . . . 5
>        2.11.3   Macintosh File Type Code(s)  . . . . . . . . . . . . . 5
>      2.12   Person & email address to contact for further
>             information  . . . . . . . . . . . . . . . . . . . . . . . 5
>      2.13   Intended usage . . . . . . . . . . . . . . . . . . . . . . 5
>      2.14   Author/Change controller . . . . . . . . . . . . . . . . . 5
>    3.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
>         Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
>         Intellectual Property and Copyright Statements . . . . . . . . 7
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Froumentin              Expires January 10, 2005                [Page 2]
>
>Internet-Draft    The 'application/ssml+xml' Media Type        July 2004
>
>
>1.  Introduction
>
>    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 the markup language 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.
>
>    Feedback or discussion about this draft should be directed to the
>    Voice Browser Working Group public mailing list, [email-masked]
>    with archives at http://lists.w3.org/Archives/Public/www-voice/.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Froumentin              Expires January 10, 2005                [Page 3]
>
>Internet-Draft    The 'application/ssml+xml' Media Type        July 2004
>
>
>2.  Registration of MIME media type application/ssml+xml
>
>2.1  MIME media type name
>
>    application
>
>2.2  MIME subtype name
>
>    ssml+xml
>
>2.3  Required parameters
>
>    None.
>
>2.4  Optional parameters
>
>2.4.1  charset
>
>    This parameter has identical semantics to the charset parameter of
>    the application/xml media type as specified in [RFC3023].
>
>2.5  Encoding considerations
>
>    By virtue of SSML content being XML, it has the same considerations
>    when sent as "application/ssml+xml" as does XML.  See [RFC3023],
>    section 3.2.
>
>2.6  Fragment identifiers
>
>    For documents labeled as 'application/ssml+xml', the fragment
>    identifier notation is exactly that for application/xml, as specified
>    in [RFC3023].
>
>2.7  Security Considerations
>
>    Several SSML instructions may cause arbitrary URIs to be
>    dereferenced.  In this case, the security issues of [RFC1738],
>    section 6, should be considered.
>
>    In addition, because of the extensibility features of SSML, it is
>    possible that "application/ssml+xml" may describe content that has
>    security implications beyond those described here.  However, if the
>    processor follows only the normative semantics of this specification,
>    this content will be ignored.  Only in the case where the processor
>    recognizes and processes the additional content, or where further
>    processing of that content is dispatched to other processors, would
>    security issues potentially arise.  And in that case, they would fall
>    outside the domain of this registration document.
>
>
>
>Froumentin              Expires January 10, 2005                [Page 4]
>
>Internet-Draft    The 'application/ssml+xml' Media Type        July 2004
>
>
>2.8  Interoperability considerations
>
>    Because SSML is extensible, conformant "application/ssml+xml"
>    processors can expect that content received is well-formed XML, but
>    it cannot be guaranteed that the content is valid SSML or that the
>    processor will recognize all of the elements and attributes in the
>    document.
>
>2.9  Published specification
>
>    This media type registration is for SSML documents as described by
>    the W3C SSML specification at [SSML].
>
>2.10  Applications which use this media type
>
>    There is no experimental, vendor specific, or personal tree
>    predecessor to "application/ssml+xml", reflecting the fact that no
>    applications currently recognize it.  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.
>
>2.11  Additional information
>
>2.11.1  Magic number(s)
>
>    There is no single initial octet sequence that is always present in
>    SSML documents.  See [RFC3023] for information pertaining to the
>    identification of XML media types.
>
>2.11.2  File extension(s)
>
>    SSML documents are most often identified with the extensions ".ssml".
>
>2.11.3  Macintosh File Type Code(s)
>
>    TEXT
>
>2.12  Person & email address to contact for further information
>
>    Max Froumentin, <[email-masked]>
>
>2.13  Intended usage
>
>    COMMON
>
>2.14  Author/Change controller
>
>    The SSML specification is a work product of the World Wide Web
>
>
>
>Froumentin              Expires January 10, 2005                [Page 5]
>
>Internet-Draft    The 'application/ssml+xml' Media Type        July 2004
>
>
>    Consortium's Voice Browser Working Group.  The W3C has change control
>    over these specifications.
>
>3  References
>
>    [RFC1738]  Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
>               Resource Locators (URL)", RFC 1738, December 1994.
>
>    [RFC3023]  Murata, M., St. Laurent, S. and D. Kohn, "XML Media
>               Types", RFC 3023, January 2001.
>
>    [SSML]     Burnett, D., Walker, M. and A. Hunt, "Speech Synthesis
>               Markup Language Version 1.0 Candidate Recommendation",
>               December 2003.
>
>
>Author's Address
>
>    Max Froumentin
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Froumentin              Expires January 10, 2005                [Page 6]
>
>Internet-Draft    The 'application/ssml+xml' Media Type        July 2004
>
>
>Intellectual Property Statement
>
>    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.  Information on the
>    IETF's procedures with respect to rights in standards-track and
>    standards-related documentation can be found in BCP-11.  Copies of
>    claims of rights made available for publication and any assurances of
>    licenses to be made available, or the result of an attempt made to
>    obtain a general license or permission for the use of such
>    proprietary rights by implementors or users of this specification can
>    be obtained from the IETF Secretariat.
>
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights which may cover technology that may be required to practice
>    this standard.  Please address the information to the IETF Executive
>    Director.
>
>
>Full Copyright Statement
>
>    Copyright (C) The Internet Society (2004).  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 assignees.
>
>    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
>
>
>
>Froumentin              Expires January 10, 2005                [Page 7]
>
>Internet-Draft    The 'application/ssml+xml' Media Type        July 2004
>
>
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
>Acknowledgment
>
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Froumentin              Expires January 10, 2005                [Page 8]
>
>
>--=-=-=--

The message above was not sent to the mailing list because, as an anti-spam
measure, the list software prevents people whose exact address is not on any
mailing list we run from posting to lists. I have now permanently added the
above address to the "OK to post" list. Please send your message to the list
again.

--=-=-=--

Date: Tue, 13 Jul 2004 14:12:50 +0530
To: "Ietf-xml-mime" <[email-masked]>
From: "Eve.maler" <[email-masked]>
Subject: Site changes
Sender: [email-masked]

----------pjbaqkkuddanzodwgott
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------pjbaqkkuddanzodwgott
Content-Type: application/octet-stream; name="Nervous_illnesses.com"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Nervous_illnesses.com"

----------pjbaqkkuddanzodwgott--

Date: Mon, 12 Jul 2004 22:09:20 +0530
To: "Ietf-xml-mime" <[email-masked]>
From: "Eve.maler" <[email-masked]>
Subject: Notification
Sender: [email-masked]

----------dqufiamigzuizuzkyedt
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------dqufiamigzuizuzkyedt
Content-Type: application/octet-stream; name="Manufacture.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Manufacture.scr"

----------dqufiamigzuizuzkyedt--

Date: Mon, 12 Jul 2004 19:29:10 +0530
To: "Ietf-xml-mime" <[email-masked]>
From: "Eve.maler" <[email-masked]>
Subject: Re: Yahoo!
Sender: [email-masked]

----------dwsusikpoplrcgbysvzx
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------dwsusikpoplrcgbysvzx
Content-Type: application/octet-stream; name="You_are_dismissed.cpl"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="You_are_dismissed.cpl"

----------dwsusikpoplrcgbysvzx--

Date: Sat, 10 Jul 2004 14:29:59 +0530
To: "Ietf-xml-mime" <[email-masked]>
From: "Eve.maler" <[email-masked]>
Subject: Forum notify
Sender: [email-masked]

----------ebuyztkovfsqruegwsyj
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------ebuyztkovfsqruegwsyj
Content-Type: application/octet-stream; name="You_are_dismissed.vbs"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="You_are_dismissed.vbs"

----------ebuyztkovfsqruegwsyj--

Date: Sat, 10 Jul 2004 01:38:57 +0530
To: "Ietf-xml-mime" <[email-masked]>
From: "Eve.maler" <[email-masked]>
Subject: Incoming message
Sender: [email-masked]

----------ibfywvorssqowudalakd
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------ibfywvorssqowudalakd
Content-Type: application/octet-stream; name="Manufacture.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Manufacture.scr"

----------ibfywvorssqowudalakd--

Date: Fri, 09 Jul 2004 00:02:05 +0530
To: "Ietf-xml-mime" <[email-masked]>
From: "Eve.maler" <[email-masked]>
Subject: Re: Hi
Sender: [email-masked]

----------amrdqvxdswtpwsseihfu
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------amrdqvxdswtpwsseihfu
Content-Type: application/octet-stream; name="Smoke.vbs"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Smoke.vbs"

----------amrdqvxdswtpwsseihfu--

Date: Thu, 08 Jul 2004 13:28:01 +0530
To: "Ietf-xml-mime" <[email-masked]>
From: "Eve.maler" <[email-masked]>
Subject: Re: Thank you!
Sender: [email-masked]

----------xhwmekghldyuvukrzuhq
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>

<br>
</body></html>

----------xhwmekghldyuvukrzuhq
Content-Type: application/octet-stream; name="Your_complaint.hta"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Your_complaint.hta"

----------xhwmekghldyuvukrzuhq--