Subject: Request for guidance on MIME and media types
From: ben at morrow.me.uk ([email-masked])
Date: Tue Jan 3 16:22:39 2006

At  4pm on 12/12/03 you (Mark Nottingham) wrote:
> Note that a specification is being prepared that allows for 
> the use of a similar "resolve the URI to insert binary 
> characters" idiom in non-SOAP scenarios.  The general 
> technique is documented at [3] under the working title "MTOM 
> Inclusion Format For You (MIFFY)", a title that will almost 
> surely change due to copyright issues.  The proposed 
> application/soap_mtom+xml media type is thus a specific 
> example of the so-called Miffy class of encodings.  We propose 
> that a media type be assigned to each such use of Miffy, with 
> application/soap_mtom+xml being assigned as the name for the 
> application of Miffy to SOAP envelopes.

I entirely agree that a separate MIME type is appropriate; however, I
would suggest a more generic name be used, such as
application/soap+miffy+xml, with +miffy being generally used for
application-of-Miffy-to-foo types.

Ben

-- 
   If you put all the prophets,   |   You'd have so much more reason
   Mystics and saints             |   Than ever was born
   In one room together,          |   Out of all of the conflicts of time.
[email-masked] |----------------+---------------| The Levellers, 'Believers'

From: lists at unknown.nu (Kim Scarborough)
Date: Sun Dec 21 20:54:10 2003
Subject: Proposed Registration of MIME media type application/vnd.wordperfect
Message-ID: <[email-masked]>

> What is the relationship of this to
>   http://www.iana.org/assignments/media-types/application/wordperfect5.1
> ?

Well, the problem with that was that they appended the version string on
the end of the name, so nobody uses it anymore (WordPerfect is up to
version 11 now--5.1 was only for DOS and Unix CLI). It's too bad it was
registered that way, but it's too late now, so I figured I'd submit this.
Also, RFC 2048 encourages re-registering grandfathered media types, so
what the heck.

-- 
-------------------------------------------------------------------------------
Kim Scarborough                                      http://www.unknown.nu/kim/
-------------------------------------------------------------------------------
>From [email-masked]  Sat Dec 13 01:01:14 2003
From: mark.nottingham at bea.com (Mark Nottingham)
Date: Sun Dec 28 19:33:32 2003
Subject: Request for guidance on MIME and media types
Message-ID: <[email-masked]>

The W3C XML Protocol Working Group is currently working on the Message 
Transmission Optimisation Mechanism (MTOM)[1], which allows more 
efficient transmission of SOAP envelopes [2] by changing their 
on-the-wire XML serialisation.

Registration of the "application/soap+xml" media type is currently 
under way, so that SOAP envelopes (i.e. the XML construct that SOAP 
defines) can be identified in MIME and MIME-like systems. We anticipate 
the need to likewise identify MTOM messages in these systems, and would 
like to solicit guidance about the best way to do so.

Whereas the XML 1.0 serialisation of SOAP is self-contained, MTOM 
serialisation will only use XML for a subset of the envelope data. 
Other portions of the envelope will be transmitted in separate binary 
entities, typically but not necessarily in a multipart/related MIME 
message, and those entities will be referenced with URIs from the 
envelope (which, when using multipart/related, would reside in the root 
part).

A simplistic example might be;

---8<---
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; 
type=application/soap_mtom+xml;
         start="<[email-masked]>"

--MIME_boundary
Content-Type: application/soap_mtom+xml
Content-Transfer-Encoding: 8bit
Content-ID: <[email-masked]>

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="...">
<SOAP-ENV:Body>
   <!--- xml content here -->
   <Image type="image/jpeg"><Include xmlns="..."
     href="cid:[email-masked]"/></Image>
   <!--- xml content here -->
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <[email-masked]>

[binary image]
--MIME_boundary--
---8<---

Which could be transformed to this XML -

---8<---
<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="...">
<SOAP-ENV:Body>
   <!--- xml content here -->
   <Image type="image/jpeg">[base64-encoded image]</Image>
   <!--- xml content here -->
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
---8<---

The XML that is transmitted by MTOM is thus distinct from 
application/soap+xml in at least the following respects:

* It contains some but not all of the envelope data. Indeed, in the 
common case where multipart MIME is used, it's the entire package that 
conveys the same information as application/soap+xml.

* Its semantics are different from those of a SOAP envelope. The usual 
semantic for a SOAP envelope is to apply the SOAP processing model; the 
semantics of an MTOM envelope are to to resolve the link URIs to create 
a new Infoset, which is in turn processable by the SOAP model.

Therefore, it appears that the application/soap+xml media type, as 
currently defined, is not appropriate to describe the XML format 
created by MTOM.

We've considered several possible alternatives, including 1) use of a 
HTTP content-coding (which we rejected, both because content-codings 
are a HTTP-specific mechanism, whereas we intend to use this encoding 
in other protocols, possibly including MIME-based protocols, and 
because doing so would require labelling the HTTP entity with an 
"application/soap+xml" media type, which would mask the presence of 
multipart MIME), and 2) a MIME content-transfer-encoding (which we 
rejected because registration of new CTEs is discouraged by RFC2045).

Therefore, we believe that it would be most suitable to register a new 
media type, e.g., "application/soap_mtom+xml". This media type would 
identify the XML pre-MTOM processing (i.e., with the URIs to be 
referenced still embedded), possibly (but not necessarily) located 
inside a multipart/related package.

Note that a specification is being prepared that allows for the use of 
a similar "resolve the URI to insert binary characters" idiom in 
non-SOAP scenarios.  The general technique is documented at [3] under 
the working title "MTOM Inclusion Format For You (MIFFY)", a title that 
will almost surely change due to copyright issues.  The proposed 
application/soap_mtom+xml media type is thus a specific example of the 
so-called Miffy class of encodings.  We propose that a media type be 
assigned to each such use of Miffy, with application/soap_mtom+xml 
being assigned as the name for the application of Miffy to SOAP 
envelopes.

We would appreciate any input as to whether this is the most 
appropriate way to flag the use of an alternate serialisation of an XML 
format in MIME, and/or pointers to guidance on this matter.

1. http://www.w3.org/TR/soap12-mtom/
2. http://www.w3.org/TR/soap12-part0/
3. http://www.w3.org/mid/[email-masked]

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

From: lists at unknown.nu (Kim Scarborough)
Date: Tue Jan  3 16:22:39 2006
Subject: Proposed Registration of MIME media type application/vnd.wordperfect
Message-ID: <[email-masked]>

> What is the relationship of this to
>   http://www.iana.org/assignments/media-types/application/wordperfect5.1
> ?

Well, the problem with that was that they appended the version string on
the end of the name, so nobody uses it anymore (WordPerfect is up to
version 11 now--5.1 was only for DOS and Unix CLI). It's too bad it was
registered that way, but it's too late now, so I figured I'd submit this.
Also, RFC 2048 encourages re-registering grandfathered media types, so
what the heck.

-- 
-------------------------------------------------------------------------------
Kim Scarborough                                      http://www.unknown.nu/kim/
-------------------------------------------------------------------------------

From: LMM at acm.org (Larry Masinter)
Date: Sun Dec 21 08:25:54 2003
Subject: Proposed Registration of MIME media type application/vnd.wordperfect
In-Reply-To: <[email-masked]>
Message-ID: <000701c3c793$a0fc38f0$6701a8c0@MasinterT40>

What is the relationship of this to
  http://www.iana.org/assignments/media-types/application/wordperfect5.1
?

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:39 2006
Subject: Proposed Registration of MIME media type application/vnd.wordperfect
In-Reply-To: <[email-masked]>
Message-ID: <000701c3c793$a0fc38f0$6701a8c0@MasinterT40>

What is the relationship of this to
  http://www.iana.org/assignments/media-types/application/wordperfect5.1
?

From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Tue Jan  3 16:22:39 2006
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <4.2.0.58.J.20031219133801.06ffa768@localhost>
References: <[email-masked]> <4.2.0.58.J.20031219133801.06ffa768@localhost>
Message-ID: <[email-masked]>

> There are two separate issues:
> 1) Does a registration allow the 'charset' parameter or not.
> 2) Does an actual entity have the 'charset' parameter or not.
> 
> It is not totally clear to me which one of these you are talking above.

1)

> In my opinion, it is highly preferable that all registrations
> allow the 'charset' parameter, to avoid a patchwork. The draft
> should contain some justification for this.

RFC 3023 already provides a registration template which introduces the 
charset parameter.  But the recommendation to introduce the charset parameter 
is a SHOULD rather than a MUST.  People read RFC 3023 but they intentionally 
dropped the charset.

I studied existing +xml media types registered at IANA.  
Here is the result.

1. IETF tree

With the exception of application/cnrp+xml, all +xml media types 
have the charset parameter.

1) beep+xml  	[RFC3080]
This keeps the charset parameter.

2) cnrp+xml  	[RFC3367]
This omits the charset parameter.  Not restricted to UTF-8.

3) cpl+xml 	[RFCXXXX]	
http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-08.txt
This keeps the charset parameter.

4) pidf+xml 	[RFC-ietf-impp-cpim-pidf-08.txt]
http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-08.txt
This keeps the charset parameter.

5) reginfo+xml 	[RFC-ietf-sipping-reg-event-00.txt]
http://www.ietf.org/internet-drafts/draft-ietf-sipping-reg-event-00.txt
This keeps the charset parameter.

6) watcherinfo+xml 	[RFC-ietf-simple-winfo-format-04.txt]
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-04.txt
This keeps the charset parameter.

7) xhtml+xml 	[RFC3236]
http://www.rfc-editor.org/rfc/rfc3236.txt
This keeps the charset parameter.

2. Vendor tree

Only two media types have the charset parameter.  Since media types in
the vendor tree do not always have accompanying documents, we do not
know if there are good reasons to omit the charset.

1) vnd.criticaltools.wbs+xml 	[Spiller]

http://www.iana.org/assignments/media-types/application/vnd.criticaltools.wbs+xml
This omits the charset parameter.
The details of this structure are proprietary to Critical Tools, Inc.

2) vnd.irepository.package+xml 	[Knowles]

http://www.iana.org/assignments/media-types/application/vnd.irepository.package+xml
This omits the charset parameter.
Use of this MIME type is limited to users of Lucidoc and associated
document management tools published by iRepository.net, Inc.

3) vnd.liberty-request+xml 	[McDowell]

http://www.iana.org/assignments/media-types/application/vnd.liberty-request+xml
This omits the charset parameter.

4) vnd.llamagraphics.life-balance.exchange+xml 	[White]

http://www.iana.org/assignments/media-types/application/vnd.llamagraphics.life-balance.exchange+xml
This keeps the charset parameter.

5) vnd.mozilla.xul+xml 	[McDaniel]

http://www.iana.org/assignments/media-types/application/vnd.mozilla.xul+xml
This keeps the charset parameter.

6) vnd.pwg-xhtml-print+xml 	[Wright]

http://www.iana.org/assignments/media-types/application/vnd.pwg-xhtml-print+xml
This omits the charset parameter.

7) vnd.wv.csp+xml 	[Ingimundarson]

http://www.iana.org/assignments/media-types/application/vnd.wv.csp+xml
This omits the charset parameter.  
They wrote "No parameters are required - covered by client-server capability
negotiation."

8) vnd.wv.csp+wbxml 	[Salmi]

http://www.iana.org/assignments/media-types/application/vnd.wv.csp+wbxml
This omits the charset parameter.  
They wrote "No parameters are required since WV capability negotiation
covers this."

9) vnd.wv.ssp+xml 	[Ingimundarson]

http://www.iana.org/assignments/media-types/application/vnd.wv.ssp+xml
This omits the charset parameter.  

> As for whether the actual entity should come with a 'charset'
> parameter, we should also have a discussion of the various
> issues in the draft.
> 
> 
> >By the way, "The Standard Hex Format" uses UTF-8 only.
> >
> >http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt
> 
> I have not found 'UTF-8' anywhere in this document, so I'm not
> sure where you saw this restriction.

I am afraid that I made a mistake.  We have discussed this issue in 
the mailing list, but nothing is written down yet.

> Another one is
> http://www.ietf.org/internet-drafts/draft-sbml-media-type-02.txt.
> 
> This was approved by the IESG yesterday, so I guess it's too late
> to try to change it. In practice, I very much hope that no implementation
> will reject sbml data that comes with a redundant charset=utf-8.

Now we have two exceptions in the IETF tree.

Practically, what can we do?

Cheers,

-- 
MURATA Makoto <[email-masked]>

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:39 2006
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <[email-masked]>
References: <4.2.0.58.J.20031218112549.00a93ad0@localhost> <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031218112549.00a93ad0@localhost>
Message-ID: <4.2.0.58.J.20031219133801.06ffa768@localhost>

Hello Makoto,

At 00:20 03/12/20 +0900, MURATA Makoto wrote:

>On Thu, 18 Dec 2003 11:30:44 -0500
>Martin Duerst <[email-masked]> wrote:
>
> > There is some work starting on updating RFC 3023, and we hope that
> > we can use it to document the issues and questions that have
> > come up on the list. Chris has volunteered to coauthor, and I'll
> > help from the sidelines. Probably having all the information together
> > in one place, is better than having some of the information separated out.
>
>As a co-author, I also agree to add some guidelines for the omission of the
>charset parameter.  Chris and I will start this work shortly.

We are looking forward to this!

>When a media type uses UTF-8 only, I can agree to omit the charset
>parameter. "UTF-8" is already a recommended policy
>(http://www.w3.org/TR/charmod/#sec-UniqueEncoding).  I do not see strong
>reasons to specify charset="utf-8" always.  However, even in this case, I
>am sympathetic to Martin's worry ("we start to get into a patchwork").
>In all other cases, I do not want to allow omission of the charset
>parameter.  How do others feel?

There are two separate issues:
1) Does a registration allow the 'charset' parameter or not.
2) Does an actual entity have the 'charset' parameter or not.

It is not totally clear to me which one of these you are talking above.
In my opinion, it is highly preferable that all registrations
allow the 'charset' parameter, to avoid a patchwork. The draft
should contain some justification for this.

As for whether the actual entity should come with a 'charset'
parameter, we should also have a discussion of the various
issues in the draft.

>By the way, "The Standard Hex Format" uses UTF-8 only.
>
>http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt

I have not found 'UTF-8' anywhere in this document, so I'm not
sure where you saw this restriction. The document contains:

 >>>>>>>>
9.1 Optional parameters

    none.

    There is no charset parameter. Character handling has identical
    semantics to the case where the charset parameter of the
    "application/xml" media type is omitted, as described in RFC3023 [4].
 >>>>>>>>

I think this should be fixed to reinstate the charset parameter
as discussed on this mailing list.

Another one is
http://www.ietf.org/internet-drafts/draft-sbml-media-type-02.txt.

This was approved by the IESG yesterday, so I guess it's too late
to try to change it. In practice, I very much hope that no implementation
will reject sbml data that comes with a redundant charset=utf-8.

Regards,    Martin.

From: distobj at acm.org (Mark Baker)
Date: Fri Dec 19 18:26:36 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <[email-masked]>; from [email-masked] on Sat, Dec 20, 2003 at 12:20:01AM +0900
References: <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031218112549.00a93ad0@localhost> <[email-masked]>
Message-ID: <[email-masked]>

On Sat, Dec 20, 2003 at 12:20:01AM +0900, MURATA Makoto wrote:
> However, even in this case, I
> am sympathetic to Martin's worry ("we start to get into a patchwork").
> In all other cases, I do not want to allow omission of the charset
> parameter.  How do others feel?

Do we know that all existing application/*+xml types define the charset
param by reference to 3023?  If so, then I agree;  I believe that the
benefit of this simplification outweighs the cost of (potential)
redundancy.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [email-masked]  Fri Dec 19 19:55:31 2003
From: duerst at w3.org (Martin Duerst)
Date: Fri Dec 19 19:55:46 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <[email-masked]>
References: <4.2.0.58.J.20031218112549.00a93ad0@localhost>
	<1071764448.22957.11.camel@felicia>
	<4.2.0.58.J.20031218112549.00a93ad0@localhost>
Message-ID: <4.2.0.58.J.20031219133801.06ffa768@localhost>

Hello Makoto,

At 00:20 03/12/20 +0900, MURATA Makoto wrote:

>On Thu, 18 Dec 2003 11:30:44 -0500
>Martin Duerst <[email-masked]> wrote:
>
> > There is some work starting on updating RFC 3023, and we hope that
> > we can use it to document the issues and questions that have
> > come up on the list. Chris has volunteered to coauthor, and I'll
> > help from the sidelines. Probably having all the information together
> > in one place, is better than having some of the information separated out.
>
>As a co-author, I also agree to add some guidelines for the omission of the
>charset parameter.  Chris and I will start this work shortly.

We are looking forward to this!

>When a media type uses UTF-8 only, I can agree to omit the charset
>parameter. "UTF-8" is already a recommended policy
>(http://www.w3.org/TR/charmod/#sec-UniqueEncoding).  I do not see strong
>reasons to specify charset="utf-8" always.  However, even in this case, I
>am sympathetic to Martin's worry ("we start to get into a patchwork").
>In all other cases, I do not want to allow omission of the charset
>parameter.  How do others feel?

There are two separate issues:
1) Does a registration allow the 'charset' parameter or not.
2) Does an actual entity have the 'charset' parameter or not.

It is not totally clear to me which one of these you are talking above.
In my opinion, it is highly preferable that all registrations
allow the 'charset' parameter, to avoid a patchwork. The draft
should contain some justification for this.

As for whether the actual entity should come with a 'charset'
parameter, we should also have a discussion of the various
issues in the draft.

>By the way, "The Standard Hex Format" uses UTF-8 only.
>
>http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt

I have not found 'UTF-8' anywhere in this document, so I'm not
sure where you saw this restriction. The document contains:

 >>>>>>>>
9.1 Optional parameters

    none.

    There is no charset parameter. Character handling has identical
    semantics to the case where the charset parameter of the
    "application/xml" media type is omitted, as described in RFC3023 [4].
 >>>>>>>>

I think this should be fixed to reinstate the charset parameter
as discussed on this mailing list.

Another one is
http://www.ietf.org/internet-drafts/draft-sbml-media-type-02.txt.

This was approved by the IESG yesterday, so I guess it's too late
to try to change it. In practice, I very much hope that no implementation
will reject sbml data that comes with a redundant charset=utf-8.

Regards,    Martin.
>From [email-masked]  Sat Dec 20 15:52:56 2003
From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Sat Dec 20 15:56:22 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <4.2.0.58.J.20031219133801.06ffa768@localhost>
References: <[email-masked]>
	<4.2.0.58.J.20031219133801.06ffa768@localhost>
Message-ID: <[email-masked]>

> There are two separate issues:
> 1) Does a registration allow the 'charset' parameter or not.
> 2) Does an actual entity have the 'charset' parameter or not.
> 
> It is not totally clear to me which one of these you are talking above.

1)

> In my opinion, it is highly preferable that all registrations
> allow the 'charset' parameter, to avoid a patchwork. The draft
> should contain some justification for this.

RFC 3023 already provides a registration template which introduces the 
charset parameter.  But the recommendation to introduce the charset parameter 
is a SHOULD rather than a MUST.  People read RFC 3023 but they intentionally 
dropped the charset.

I studied existing +xml media types registered at IANA.  
Here is the result.

1. IETF tree

With the exception of application/cnrp+xml, all +xml media types 
have the charset parameter.

1) beep+xml  	[RFC3080]
This keeps the charset parameter.

2) cnrp+xml  	[RFC3367]
This omits the charset parameter.  Not restricted to UTF-8.

3) cpl+xml 	[RFCXXXX]	
http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-08.txt
This keeps the charset parameter.

4) pidf+xml 	[RFC-ietf-impp-cpim-pidf-08.txt]
http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-08.txt
This keeps the charset parameter.

5) reginfo+xml 	[RFC-ietf-sipping-reg-event-00.txt]
http://www.ietf.org/internet-drafts/draft-ietf-sipping-reg-event-00.txt
This keeps the charset parameter.

6) watcherinfo+xml 	[RFC-ietf-simple-winfo-format-04.txt]
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-04.txt
This keeps the charset parameter.

7) xhtml+xml 	[RFC3236]
http://www.rfc-editor.org/rfc/rfc3236.txt
This keeps the charset parameter.

2. Vendor tree

Only two media types have the charset parameter.  Since media types in
the vendor tree do not always have accompanying documents, we do not
know if there are good reasons to omit the charset.

1) vnd.criticaltools.wbs+xml 	[Spiller]

http://www.iana.org/assignments/media-types/application/vnd.criticaltools.wbs+xml
This omits the charset parameter.
The details of this structure are proprietary to Critical Tools, Inc.

2) vnd.irepository.package+xml 	[Knowles]

http://www.iana.org/assignments/media-types/application/vnd.irepository.package+xml
This omits the charset parameter.
Use of this MIME type is limited to users of Lucidoc and associated
document management tools published by iRepository.net, Inc.

3) vnd.liberty-request+xml 	[McDowell]

http://www.iana.org/assignments/media-types/application/vnd.liberty-request+xml
This omits the charset parameter.

4) vnd.llamagraphics.life-balance.exchange+xml 	[White]

http://www.iana.org/assignments/media-types/application/vnd.llamagraphics.life-balance.exchange+xml
This keeps the charset parameter.

5) vnd.mozilla.xul+xml 	[McDaniel]

http://www.iana.org/assignments/media-types/application/vnd.mozilla.xul+xml
This keeps the charset parameter.

6) vnd.pwg-xhtml-print+xml 	[Wright]

http://www.iana.org/assignments/media-types/application/vnd.pwg-xhtml-print+xml
This omits the charset parameter.

7) vnd.wv.csp+xml 	[Ingimundarson]

http://www.iana.org/assignments/media-types/application/vnd.wv.csp+xml
This omits the charset parameter.  
They wrote "No parameters are required - covered by client-server capability
negotiation."

8) vnd.wv.csp+wbxml 	[Salmi]

http://www.iana.org/assignments/media-types/application/vnd.wv.csp+wbxml
This omits the charset parameter.  
They wrote "No parameters are required since WV capability negotiation
covers this."

9) vnd.wv.ssp+xml 	[Ingimundarson]

http://www.iana.org/assignments/media-types/application/vnd.wv.ssp+xml
This omits the charset parameter.  

> As for whether the actual entity should come with a 'charset'
> parameter, we should also have a discussion of the various
> issues in the draft.
> 
> 
> >By the way, "The Standard Hex Format" uses UTF-8 only.
> >
> >http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt
> 
> I have not found 'UTF-8' anywhere in this document, so I'm not
> sure where you saw this restriction.

I am afraid that I made a mistake.  We have discussed this issue in 
the mailing list, but nothing is written down yet.

> Another one is
> http://www.ietf.org/internet-drafts/draft-sbml-media-type-02.txt.
> 
> This was approved by the IESG yesterday, so I guess it's too late
> to try to change it. In practice, I very much hope that no implementation
> will reject sbml data that comes with a redundant charset=utf-8.

Now we have two exceptions in the IETF tree.

Practically, what can we do?

Cheers,

-- 
MURATA Makoto <[email-masked]>

From: distobj at acm.org (Mark Baker)
Date: Tue Jan  3 16:22:39 2006
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <[email-masked]>; from [email-masked] on Sat, Dec 20, 2003 at 12:20:01AM +0900
References: <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031218112549.00a93ad0@localhost> <[email-masked]>
Message-ID: <[email-masked]>

On Sat, Dec 20, 2003 at 12:20:01AM +0900, MURATA Makoto wrote:
> However, even in this case, I
> am sympathetic to Martin's worry ("we start to get into a patchwork").
> In all other cases, I do not want to allow omission of the charset
> parameter.  How do others feel?

Do we know that all existing application/*+xml types define the charset
param by reference to 3023?  If so, then I agree;  I believe that the
benefit of this simplification outweighs the cost of (potential)
redundancy.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Tue Jan  3 16:22:39 2006
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <4.2.0.58.J.20031218112549.00a93ad0@localhost>
References: <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031218112549.00a93ad0@localhost>
Message-ID: <[email-masked]>

On Thu, 18 Dec 2003 11:30:44 -0500
Martin Duerst <[email-masked]> wrote:

> There is some work starting on updating RFC 3023, and we hope that
> we can use it to document the issues and questions that have
> come up on the list. Chris has volunteered to coauthor, and I'll
> help from the sidelines. Probably having all the information together
> in one place, is better than having some of the information separated out.

As a co-author, I also agree to add some guidelines for the omission of the 
charset parameter.  Chris and I will start this work shortly.

When a media type uses UTF-8 only, I can agree to omit the charset
parameter. "UTF-8" is already a recommended policy
(http://www.w3.org/TR/charmod/#sec-UniqueEncoding).  I do not see strong 
reasons to specify charset="utf-8" always.  However, even in this case, I
am sympathetic to Martin's worry ("we start to get into a patchwork").
In all other cases, I do not want to allow omission of the charset
parameter.  How do others feel?

By the way, "The Standard Hex Format" uses UTF-8 only.

http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt

Cheers,

-- 
MURATA Makoto <[email-masked]>

From: lists at unknown.nu (Kim Scarborough)
Date: Tue Jan  3 16:22:39 2006
Subject: Proposed Registration of MIME media type application/vnd.wordperfect
Message-ID: <[email-masked]>

MIME media type name:		application

MIME subtype name:		vnd.wordperfect

Required parameters:		none

Optional parameters:		none

Encoding Considerations:	

	Wordperfect files are binary data and should be suitably encoded for
	protocols that do not handle binary data.

Security Considerations:

	The security issues associated with this type have not been assessed.

Interoperability considerations:

	As this is not an open standard, interoperability is left up to the
	discretion of the developer (currently Corel Corp.).

Published specification:	none

Applications which use this media type:

	The WordPerfect suite of office applications.

Additional information:

	Magic number(s):	none

	File extension:		.wpd

	Macintosh File Type Code(s):	"WPC2"

Person & email address to contact for further information:

	Questions about this proposal should be directed to Kim
	Scarborough <[email-masked]>.

Intended usage:		COMMON

Author/Change controller:

	Corel Corporation
	1600 Carling Avenue
	Ottawa, Ontario
	Canada
	K1Z 8R7

From: duerst at w3.org (Martin Duerst)
Date: Thu Dec 18 21:56:57 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <[email-masked]>
References: <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost> <1071764448.22957.11.camel@felicia>
Message-ID: <4.2.0.58.J.20031218132824.07129d38@localhost>

At 19:15 03/12/18 +0100, Max Froumentin wrote:
>Linus Walleij <[email-masked]> wrote:

> > OK so then I regard this as official W3.org policy on transport type.
>
>I expect that that policy would rather be set by the TAG. See:
>http://www.w3.org/2001/tag/2002/0129-mime
>
>"Thus there is no ambiguity when the charset is omitted, and the
>STRONGLY RECOMMENDED injunction [in RFC3023] to use the charset is
>misplaced for application/xml and for non-text "+xml"
>types.

I agree that we should change the 'strongly recommended' to a
more balanced wording and a more detailed discussion in
the upcomming RFC 3023 update.

I also just found out that there are apparently two findings
dealing with the above issue, the other one (still at draft
stage) at http://www.w3.org/2001/tag/doc/mime-respect-20031210.html
(diff at
http://www.w3.org/2001/tag/doc/mime-respect-20031210-diff.html).

>Consequently, for XML representations, server-side applications
>SHOULD only supply a charset header when there is complete certainty
>as to the encoding in use. Otherwise, an error will cause a perfectly
>usable representation to be rejected by an architecturally sound
>client."

I think that this is basically right, but highly overstated.
There are two points:

1) It implies that leaving off the charset parameter will always
    lead to perfectly correct documents.
    While there are certain cases where indeed leaving out the
    charset parameter will improve things, when the charset
    parameter is wrong, there are also cases where things will
    get worse, and there are cases where things are not affected.

2) The language used seems to be inappropriate for a specification,
    because specifications in general assume that people do what
    the spec says. If we would fill up our specs with notes saying
    that you shouldn't do this if you don't get it right, our specs
    would all be much longer and much more difficult to read.

In addition, note that the finding you cited continues as follows:

 >>>>>>>>
We recommend that section 7.1 of [RFC3023] be amended to something like the 
following:

     The use of the charset parameter, when the charset is reliably known 
and agrees with the encoding declaration, is RECOMMENDED, since this 
information can be used by non-XML processors to determine authoritatively 
the charset of the XML MIME entity.
 >>>>>>>>

So it does not look to me that the TAG is recommending to remove
the charset parameter from application/foo+xml registrations.

Regards,     Martin.
>From [email-masked]  Thu Dec 18 22:54:58 2003
From: lists at unknown.nu (Kim Scarborough)
Date: Thu Dec 18 22:55:03 2003
Subject: Proposed Registration of MIME media type application/vnd.wordperfect
Message-ID: <[email-masked]>

MIME media type name:		application

MIME subtype name:		vnd.wordperfect

Required parameters:		none

Optional parameters:		none

Encoding Considerations:	

	Wordperfect files are binary data and should be suitably encoded for
	protocols that do not handle binary data.

Security Considerations:

	The security issues associated with this type have not been assessed.

Interoperability considerations:

	As this is not an open standard, interoperability is left up to the
	discretion of the developer (currently Corel Corp.).

Published specification:	none

Applications which use this media type:

	The WordPerfect suite of office applications.

Additional information:

	Magic number(s):	none

	File extension:		.wpd

	Macintosh File Type Code(s):	"WPC2"

Person & email address to contact for further information:

	Questions about this proposal should be directed to Kim
	Scarborough <[email-masked]>.

Intended usage:		COMMON

Author/Change controller:

	Corel Corporation
	1600 Carling Avenue
	Ottawa, Ontario
	Canada
	K1Z 8R7
>From [email-masked]  Fri Dec 19 16:20:01 2003
From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Fri Dec 19 16:23:27 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <4.2.0.58.J.20031218112549.00a93ad0@localhost>
References: <1071764448.22957.11.camel@felicia>
	<4.2.0.58.J.20031218112549.00a93ad0@localhost>
Message-ID: <[email-masked]>

On Thu, 18 Dec 2003 11:30:44 -0500
Martin Duerst <[email-masked]> wrote:

> There is some work starting on updating RFC 3023, and we hope that
> we can use it to document the issues and questions that have
> come up on the list. Chris has volunteered to coauthor, and I'll
> help from the sidelines. Probably having all the information together
> in one place, is better than having some of the information separated out.

As a co-author, I also agree to add some guidelines for the omission of the 
charset parameter.  Chris and I will start this work shortly.

When a media type uses UTF-8 only, I can agree to omit the charset
parameter. "UTF-8" is already a recommended policy
(http://www.w3.org/TR/charmod/#sec-UniqueEncoding).  I do not see strong 
reasons to specify charset="utf-8" always.  However, even in this case, I
am sympathetic to Martin's worry ("we start to get into a patchwork").
In all other cases, I do not want to allow omission of the charset
parameter.  How do others feel?

By the way, "The Standard Hex Format" uses UTF-8 only.

http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt

Cheers,

-- 
MURATA Makoto <[email-masked]>

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:39 2006
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <[email-masked]>
References: <1071764448.22957.11.camel@felicia> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost> <1071764448.22957.11.camel@felicia>
Message-ID: <4.2.0.58.J.20031218132824.07129d38@localhost>

At 19:15 03/12/18 +0100, Max Froumentin wrote:
>Linus Walleij <[email-masked]> wrote:

> > OK so then I regard this as official W3.org policy on transport type.
>
>I expect that that policy would rather be set by the TAG. See:
>http://www.w3.org/2001/tag/2002/0129-mime
>
>"Thus there is no ambiguity when the charset is omitted, and the
>STRONGLY RECOMMENDED injunction [in RFC3023] to use the charset is
>misplaced for application/xml and for non-text "+xml"
>types.

I agree that we should change the 'strongly recommended' to a
more balanced wording and a more detailed discussion in
the upcomming RFC 3023 update.

I also just found out that there are apparently two findings
dealing with the above issue, the other one (still at draft
stage) at http://www.w3.org/2001/tag/doc/mime-respect-20031210.html
(diff at
http://www.w3.org/2001/tag/doc/mime-respect-20031210-diff.html).

>Consequently, for XML representations, server-side applications
>SHOULD only supply a charset header when there is complete certainty
>as to the encoding in use. Otherwise, an error will cause a perfectly
>usable representation to be rejected by an architecturally sound
>client."

I think that this is basically right, but highly overstated.
There are two points:

1) It implies that leaving off the charset parameter will always
    lead to perfectly correct documents.
    While there are certain cases where indeed leaving out the
    charset parameter will improve things, when the charset
    parameter is wrong, there are also cases where things will
    get worse, and there are cases where things are not affected.

2) The language used seems to be inappropriate for a specification,
    because specifications in general assume that people do what
    the spec says. If we would fill up our specs with notes saying
    that you shouldn't do this if you don't get it right, our specs
    would all be much longer and much more difficult to read.

In addition, note that the finding you cited continues as follows:

 >>>>>>>>
We recommend that section 7.1 of [RFC3023] be amended to something like the 
following:

     The use of the charset parameter, when the charset is reliably known 
and agrees with the encoding declaration, is RECOMMENDED, since this 
information can be used by non-XML processors to determine authoritatively 
the charset of the XML MIME entity.
 >>>>>>>>

So it does not look to me that the TAG is recommending to remove
the charset parameter from application/foo+xml registrations.

Regards,     Martin.

From: mf at w3.org (Max Froumentin)
Date: Tue Jan  3 16:22:39 2006
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <1071764448.22957.11.camel@felicia> (Linus Walleij's message of "Thu, 18 Dec 2003 17:20:51 +0100")
References: <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost> <1071764448.22957.11.camel@felicia>
Message-ID: <[email-masked]>

Linus Walleij <[email-masked]> wrote:

> ons 2003-12-17 klockan 00.12 skrev Martin Duerst:
>> Sorry I forgot to mention it, but Chris and me actually had such a
>> 'meeting' last week, and the email I wrote was the result of this
>> (and a phone call with Max).
>
> OK so then I regard this as official W3.org policy on transport type.

I expect that that policy would rather be set by the TAG. See:
http://www.w3.org/2001/tag/2002/0129-mime

"Thus there is no ambiguity when the charset is omitted, and the
STRONGLY RECOMMENDED injunction [in RFC3023] to use the charset is
misplaced for application/xml and for non-text "+xml"
types. Consequently, for XML representations, server-side applications
SHOULD only supply a charset header when there is complete certainty
as to the encoding in use. Otherwise, an error will cause a perfectly
usable representation to be rejected by an architecturally sound
client."

I don't know what Martin or Chris would have to say to that.

Max.

From: duerst at w3.org (Martin Duerst)
Date: Thu Dec 18 17:44:25 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <1071764448.22957.11.camel@felicia>
References: <4.2.0.58.J.20031216180134.06e36e20@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost>
Message-ID: <4.2.0.58.J.20031218112549.00a93ad0@localhost>

At 17:20 03/12/18 +0100, Linus Walleij wrote:
>ons 2003-12-17 klockan 00.12 skrev Martin Duerst:
>
> > Sorry I forgot to mention it, but Chris and me actually had such a
> > 'meeting' last week, and the email I wrote was the result of this
> > (and a phone call with Max).
>
>OK so then I regard this as official W3.org policy on transport type.

You can regard it as what you want. As far as I understand, it
represents our best knowledge. But it is in no way 'official' as
far as W3C is concerned.

>If you three (Martin, Chris and Max) could write up an informational
>RFC on how you believe foo/bar+xml transport types should be handled
>we could sort out this issue once and for all. I think noone would
>object to a transport type policy for XML from three W3.org members.

There is some work starting on updating RFC 3023, and we hope that
we can use it to document the issues and questions that have
come up on the list. Chris has volunteered to coauthor, and I'll
help from the sidelines. Probably having all the information together
in one place, is better than having some of the information separated out.

Regards,   Martin.
>From [email-masked]  Thu Dec 18 19:15:36 2003
From: mf at w3.org (Max Froumentin)
Date: Thu Dec 18 19:17:22 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <1071764448.22957.11.camel@felicia> (Linus Walleij's message of
	"Thu, 18 Dec 2003 17:20:51 +0100")
References: <4.2.0.58.J.20031216160942.077942a8@localhost>
	<4.2.0.58.J.20031216160942.077942a8@localhost>
	<4.2.0.58.J.20031216180134.06e36e20@localhost>
	<1071764448.22957.11.camel@felicia>
Message-ID: <[email-masked]>

Linus Walleij <[email-masked]> wrote:

> ons 2003-12-17 klockan 00.12 skrev Martin Duerst:
>> Sorry I forgot to mention it, but Chris and me actually had such a
>> 'meeting' last week, and the email I wrote was the result of this
>> (and a phone call with Max).
>
> OK so then I regard this as official W3.org policy on transport type.

I expect that that policy would rather be set by the TAG. See:
http://www.w3.org/2001/tag/2002/0129-mime

"Thus there is no ambiguity when the charset is omitted, and the
STRONGLY RECOMMENDED injunction [in RFC3023] to use the charset is
misplaced for application/xml and for non-text "+xml"
types. Consequently, for XML representations, server-side applications
SHOULD only supply a charset header when there is complete certainty
as to the encoding in use. Otherwise, an error will cause a perfectly
usable representation to be rejected by an architecturally sound
client."

I don't know what Martin or Chris would have to say to that.

Max.

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:39 2006
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <1071764448.22957.11.camel@felicia>
References: <4.2.0.58.J.20031216180134.06e36e20@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost>
Message-ID: <4.2.0.58.J.20031218112549.00a93ad0@localhost>

At 17:20 03/12/18 +0100, Linus Walleij wrote:
>ons 2003-12-17 klockan 00.12 skrev Martin Duerst:
>
> > Sorry I forgot to mention it, but Chris and me actually had such a
> > 'meeting' last week, and the email I wrote was the result of this
> > (and a phone call with Max).
>
>OK so then I regard this as official W3.org policy on transport type.

You can regard it as what you want. As far as I understand, it
represents our best knowledge. But it is in no way 'official' as
far as W3C is concerned.

>If you three (Martin, Chris and Max) could write up an informational
>RFC on how you believe foo/bar+xml transport types should be handled
>we could sort out this issue once and for all. I think noone would
>object to a transport type policy for XML from three W3.org members.

There is some work starting on updating RFC 3023, and we hope that
we can use it to document the issues and questions that have
come up on the list. Chris has volunteered to coauthor, and I'll
help from the sidelines. Probably having all the information together
in one place, is better than having some of the information separated out.

Regards,   Martin.

From: triad at df.lth.se (Linus Walleij)
Date: Tue Jan  3 16:22:39 2006
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <4.2.0.58.J.20031216180134.06e36e20@localhost>
References: <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216180134.06e36e20@localhost>
Message-ID: <1071764448.22957.11.camel@felicia>

ons 2003-12-17 klockan 00.12 skrev Martin Duerst:

> Sorry I forgot to mention it, but Chris and me actually had such a
> 'meeting' last week, and the email I wrote was the result of this
> (and a phone call with Max).

OK so then I regard this as official W3.org policy on transport type.

If you three (Martin, Chris and Max) could write up an informational
RFC on how you believe foo/bar+xml transport types should be handled
we could sort out this issue once and for all. I think noone would
object to a transport type policy for XML from three W3.org members.

What do you say?

-- 
Linus Walleij <[email-masked]>

From: moore at cs.utk.edu (Keith Moore)
Date: Wed Dec 17 22:59:13 2003
Subject: please review 'application/pdf' -- new version
In-Reply-To: <000001c3c4d5$a4c68e60$bf422099@MasinterT40>
References: <[email-masked]> <000001c3c4d5$a4c68e60$bf422099@MasinterT40>
Message-ID: <[email-masked]>

that strikes me as a reasonable way to handle the issue of what kinds of
control Adobe believes it can assert over use of PDF.  

OTOH, If the resulting draft still had statements to the effect that
implementations "must" implement the permissions stuff, I'd consider
that a separate issue.

Keith

> > The disclaimer notwithstanding, it still creates the 
> > appearance of IETF support. 
> 
> In rereviewing IETF practices in this area, I think the right
> thing to do is to remove the IPR claims from the internet
> draft. A separate IPR notice can be sent to [email-masked].
> The internet draft (and the subsequent RFC) would then contain
> the standard notice that there are IPR claims related to
> the technology in the draft.
> 
> I think this will address the issue of having an RFC
> seem to endorse the legitimacy IPR claims, despite the 
> appearance of a disclaimer.
> 
> Larry
> 
> 
>From [email-masked]  Thu Dec 18 17:20:51 2003
From: triad at df.lth.se (Linus Walleij)
Date: Thu Dec 18 17:21:05 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <4.2.0.58.J.20031216180134.06e36e20@localhost>
References: <4.2.0.58.J.20031216160942.077942a8@localhost>
	<4.2.0.58.J.20031216160942.077942a8@localhost>
	<4.2.0.58.J.20031216180134.06e36e20@localhost>
Message-ID: <1071764448.22957.11.camel@felicia>

ons 2003-12-17 klockan 00.12 skrev Martin Duerst:

> Sorry I forgot to mention it, but Chris and me actually had such a
> 'meeting' last week, and the email I wrote was the result of this
> (and a phone call with Max).

OK so then I regard this as official W3.org policy on transport type.

If you three (Martin, Chris and Max) could write up an informational
RFC on how you believe foo/bar+xml transport types should be handled
we could sort out this issue once and for all. I think noone would
object to a transport type policy for XML from three W3.org members.

What do you say?

-- 
Linus Walleij <[email-masked]>

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:39 2006
Subject: please review 'application/pdf' -- new version
In-Reply-To: <000001c3c4d5$a4c68e60$bf422099@MasinterT40>
References: <[email-masked]> <000001c3c4d5$a4c68e60$bf422099@MasinterT40>
Message-ID: <[email-masked]>

that strikes me as a reasonable way to handle the issue of what kinds of
control Adobe believes it can assert over use of PDF.  

OTOH, If the resulting draft still had statements to the effect that
implementations "must" implement the permissions stuff, I'd consider
that a separate issue.

Keith

> > The disclaimer notwithstanding, it still creates the 
> > appearance of IETF support. 
> 
> In rereviewing IETF practices in this area, I think the right
> thing to do is to remove the IPR claims from the internet
> draft. A separate IPR notice can be sent to [email-masked].
> The internet draft (and the subsequent RFC) would then contain
> the standard notice that there are IPR claims related to
> the technology in the draft.
> 
> I think this will address the issue of having an RFC
> seem to endorse the legitimacy IPR claims, despite the 
> appearance of a disclaimer.
> 
> Larry
> 
> 

From: duerst at w3.org (Martin Duerst)
Date: Wed Dec 17 21:44:29 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <[email-masked]>
References: <4.2.0.58.J.20031216160942.077942a8@localhost> <[email-masked]> <4.2.0.58.J.20031216160942.077942a8@localhost>
Message-ID: <4.2.0.58.J.20031217152847.077c2078@localhost>

Hello Ben,

[Putting [email-masked] back on the cc list, because
I think quite some of this discussion may make its way into
the next version of RFC 3023 in one way or another.]

At 18:17 03/12/17 +0000, [email-masked] wrote:
>At  4pm on 16/12/03 Martin Duerst wrote:
> > I just by chance realized that you had removed the 'charset'
> > parameter from the registration for application/voicexml+xml,
> > and also for application/ssml+xml. I have found something similar
> > in other recent registration proposals.

>The usual intent when omitting the 'charset' parameter from the
>registration is that the XML *must* be encoded in UTF8 or UTF16.

This is an interesting idea. Can you point to any actual
registrations where this is the case?

>If this is done, then the entity will not need to include a charset
>declaration in the body either, and will be universally understood
>everywhere.

Yes, this is true for application/foo+xml. For text/foo+xml,
it is not true, but then I hope nobody is talking about that anyway.

>I would suggest that those registrations which do not
>specify a charset be updated to state that encodings other than UTF8
>and UTF16 may not be used.

I'm not really sure that this helps. It would not work together
with any of the points I have brought up:

- Generic xml processors would still accept 'charset' parameters,
   even if the registration forbade it. They also would still
   accept content in other encodings (with quite some variation,
   of course), whether declared with a 'charset' parameter or
   with the encoding pseudo-attribute on an XML declaration.
- Technology such as JSP and databases would still produce
   'charset' parameters, even if the registration didn't allow it.

There may be cases where one wants a certain media type to be
restricted to UTF-8 and UTF-16 (or even in some cases only
one of them), but just saying
"no charset parameter on media type == UTF-8 or UTF-16 only"
doesn't really cut it.

Regards,    Martin.

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:39 2006
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <[email-masked]>
References: <4.2.0.58.J.20031216160942.077942a8@localhost> <[email-masked]> <4.2.0.58.J.20031216160942.077942a8@localhost>
Message-ID: <4.2.0.58.J.20031217152847.077c2078@localhost>

Hello Ben,

[Putting [email-masked] back on the cc list, because
I think quite some of this discussion may make its way into
the next version of RFC 3023 in one way or another.]

At 18:17 03/12/17 +0000, [email-masked] wrote:
>At  4pm on 16/12/03 Martin Duerst wrote:
> > I just by chance realized that you had removed the 'charset'
> > parameter from the registration for application/voicexml+xml,
> > and also for application/ssml+xml. I have found something similar
> > in other recent registration proposals.

>The usual intent when omitting the 'charset' parameter from the
>registration is that the XML *must* be encoded in UTF8 or UTF16.

This is an interesting idea. Can you point to any actual
registrations where this is the case?

>If this is done, then the entity will not need to include a charset
>declaration in the body either, and will be universally understood
>everywhere.

Yes, this is true for application/foo+xml. For text/foo+xml,
it is not true, but then I hope nobody is talking about that anyway.

>I would suggest that those registrations which do not
>specify a charset be updated to state that encodings other than UTF8
>and UTF16 may not be used.

I'm not really sure that this helps. It would not work together
with any of the points I have brought up:

- Generic xml processors would still accept 'charset' parameters,
   even if the registration forbade it. They also would still
   accept content in other encodings (with quite some variation,
   of course), whether declared with a 'charset' parameter or
   with the encoding pseudo-attribute on an XML declaration.
- Technology such as JSP and databases would still produce
   'charset' parameters, even if the registration didn't allow it.

There may be cases where one wants a certain media type to be
restricted to UTF-8 and UTF-16 (or even in some cases only
one of them), but just saying
"no charset parameter on media type == UTF-8 or UTF-16 only"
doesn't really cut it.

Regards,    Martin.

From: LMM at acm.org (Larry Masinter)
Date: Wed Dec 17 20:40:59 2003
Subject: please review 'application/pdf' -- new version
In-Reply-To: <[email-masked]>
Message-ID: <000001c3c4d5$a4c68e60$bf422099@MasinterT40>

> The disclaimer notwithstanding, it still creates the 
> appearance of IETF support. 

In rereviewing IETF practices in this area, I think the right
thing to do is to remove the IPR claims from the internet
draft. A separate IPR notice can be sent to [email-masked].
The internet draft (and the subsequent RFC) would then contain
the standard notice that there are IPR claims related to
the technology in the draft.

I think this will address the issue of having an RFC
seem to endorse the legitimacy IPR claims, despite the 
appearance of a disclaimer.

Larry

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:39 2006
Subject: please review 'application/pdf' -- new version
In-Reply-To: <[email-masked]>
Message-ID: <000001c3c4d5$a4c68e60$bf422099@MasinterT40>

> The disclaimer notwithstanding, it still creates the 
> appearance of IETF support. 

In rereviewing IETF practices in this area, I think the right
thing to do is to remove the IPR claims from the internet
draft. A separate IPR notice can be sent to [email-masked].
The internet draft (and the subsequent RFC) would then contain
the standard notice that there are IPR claims related to
the technology in the draft.

I think this will address the issue of having an RFC
seem to endorse the legitimacy IPR claims, despite the 
appearance of a disclaimer.

Larry

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:39 2006
Subject: please review 'application/pdf' -- new version
In-Reply-To: <003b01c3c4c6$5e039e50$6701a8c0@MasinterT40>
References: <[email-masked]> <003b01c3c4c6$5e039e50$6701a8c0@MasinterT40>
Message-ID: <[email-masked]>

> 
> > that's certainly better than the original text.  however, I still
> > don't want IETF endorsing Adobe's insistence that PDF permissions
> > inherently reflect the content-owner's intent, nor that viewer
> > authors "must" take away legitimate rights from those who are
> > reading the documents -which are not completely the content-owner's
> > to control.
> > 
> > would you folks please stop trying to screw the public?
> 
> Keith,
> 
> It's a little hard to work through your conspiracy-theory
> approach to the topic. Certainly I can assure you that
> there is no intent to "try to screw the public". 

PDF's DRM is very much an attempt to screw the public, since it attempts
to take away rights that the public has and transfer them to the person
who packages the document in PDF format.  That may not be precisely the
intent, but it's the effect.  Calling it a name (like "conspriacy
theory") doesn't change the fact.

> I'm not sure what in the document would need to change.

I'll try to suggest specific text.
 
> Certainly a protocol that contains an ACL represents the
> intent of the sender of the ACL about the access to the
> data that is intended to be controlled by that ACL.

Well, any protocol that trusts the recipient of a document to honor an
ACL is in a pretty dubious security position anyway.  But I don't see a
problem  with saying that this is what PDF permissions "mean".  I do see
a problem with saying that implementations "must" honor those
permissions.

> In any case, the IETF, when publishing an informational document, does
> not "endorse" the document or any IPR rights claimed in it --

The disclaimer notwithstanding, it still creates the appearance of IETF
support.  This would hardly be the first time that a vendor has tried to
get the appearance of legitimacy for a harmful practice by publishing it
as an RFC.

From: ben at morrow.me.uk ([email-masked])
Date: Wed Dec 17 19:18:32 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <4.2.0.58.J.20031216160942.077942a8@localhost>
References: <[email-masked]> <4.2.0.58.J.20031216160942.077942a8@localhost>
Message-ID: <[email-masked]>

At  4pm on 16/12/03 Martin Duerst wrote:
> I just by chance realized that you had removed the 'charset'
> parameter from the registration for application/voicexml+xml,
> and also for application/ssml+xml. I have found something similar
> in other recent registration proposals.
> 
> Here is why I think this is really not a good idea:
> 
> First, we start to get into a patchwork where some types
> allow the 'charset', and others don't. Assuming that there
> is something like generic XML processors (e.g. parsers)
> (which is the whole point of XML), how should such a parser
> know whether the 'charset' parameter is allowed or not,
> and keep up with new registrations?
> 
> Second, there are various scenarios a charset parameter in
> the header is automatically generated, or where it's much
> easier to generate it than to avoid it.
<snip>
> Again, if they use generic technology,
> getting the 'charset' into the header is much more straightforward
> than putting it into the body.

The usual intent when omitting the 'charset' parameter from the
registration is that the XML *must* be encoded in UTF8 or UTF16. If
this is done, then the entity will not need to include a charset
declaration in the body either, and will be universally understood
everywhere. I would suggest that those registrations which do not
specify a charset be updated to state that encodings other than UTF8
and UTF16 may not be used.

Ben
>From [email-masked]  Wed Dec 17 19:31:52 2003
From: moore at cs.utk.edu (Keith Moore)
Date: Wed Dec 17 19:31:57 2003
Subject: please review 'application/pdf' -- new version
In-Reply-To: <003b01c3c4c6$5e039e50$6701a8c0@MasinterT40>
References: <[email-masked]>
	<003b01c3c4c6$5e039e50$6701a8c0@MasinterT40>
Message-ID: <[email-masked]>

> 
> > that's certainly better than the original text.  however, I still
> > don't want IETF endorsing Adobe's insistence that PDF permissions
> > inherently reflect the content-owner's intent, nor that viewer
> > authors "must" take away legitimate rights from those who are
> > reading the documents -which are not completely the content-owner's
> > to control.
> > 
> > would you folks please stop trying to screw the public?
> 
> Keith,
> 
> It's a little hard to work through your conspiracy-theory
> approach to the topic. Certainly I can assure you that
> there is no intent to "try to screw the public". 

PDF's DRM is very much an attempt to screw the public, since it attempts
to take away rights that the public has and transfer them to the person
who packages the document in PDF format.  That may not be precisely the
intent, but it's the effect.  Calling it a name (like "conspriacy
theory") doesn't change the fact.

> I'm not sure what in the document would need to change.

I'll try to suggest specific text.
 
> Certainly a protocol that contains an ACL represents the
> intent of the sender of the ACL about the access to the
> data that is intended to be controlled by that ACL.

Well, any protocol that trusts the recipient of a document to honor an
ACL is in a pretty dubious security position anyway.  But I don't see a
problem  with saying that this is what PDF permissions "mean".  I do see
a problem with saying that implementations "must" honor those
permissions.

> In any case, the IETF, when publishing an informational document, does
> not "endorse" the document or any IPR rights claimed in it --

The disclaimer notwithstanding, it still creates the appearance of IETF
support.  This would hardly be the first time that a vendor has tried to
get the appearance of legitimacy for a harmful practice by publishing it
as an RFC.

From: ben at morrow.me.uk ([email-masked])
Date: Tue Jan  3 16:22:39 2006
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <4.2.0.58.J.20031216160942.077942a8@localhost>
References: <[email-masked]> <4.2.0.58.J.20031216160942.077942a8@localhost>
Message-ID: <[email-masked]>

At  4pm on 16/12/03 Martin Duerst wrote:
> I just by chance realized that you had removed the 'charset'
> parameter from the registration for application/voicexml+xml,
> and also for application/ssml+xml. I have found something similar
> in other recent registration proposals.
> 
> Here is why I think this is really not a good idea:
> 
> First, we start to get into a patchwork where some types
> allow the 'charset', and others don't. Assuming that there
> is something like generic XML processors (e.g. parsers)
> (which is the whole point of XML), how should such a parser
> know whether the 'charset' parameter is allowed or not,
> and keep up with new registrations?
> 
> Second, there are various scenarios a charset parameter in
> the header is automatically generated, or where it's much
> easier to generate it than to avoid it.
<snip>
> Again, if they use generic technology,
> getting the 'charset' into the header is much more straightforward
> than putting it into the body.

The usual intent when omitting the 'charset' parameter from the
registration is that the XML *must* be encoded in UTF8 or UTF16. If
this is done, then the entity will not need to include a charset
declaration in the body either, and will be universally understood
everywhere. I would suggest that those registrations which do not
specify a charset be updated to state that encodings other than UTF8
and UTF16 may not be used.

Ben

From: LMM at acm.org (Larry Masinter)
Date: Wed Dec 17 18:51:36 2003
Subject: please review 'application/pdf' -- new version
In-Reply-To: <[email-masked]>
Message-ID: <003b01c3c4c6$5e039e50$6701a8c0@MasinterT40>

> that's certainly better than the original text.  however, I still
don't 
> want IETF endorsing Adobe's insistence that PDF permissions inherently

> reflect the content-owner's intent, nor that viewer authors "must"
take 
> away legitimate rights from those who are reading the documents -
which 
> are not completely the content-owner's to control.
> 
> would you folks please stop trying to screw the public?

Keith,

It's a little hard to work through your conspiracy-theory
approach to the topic. Certainly I can assure you that
there is no intent to "try to screw the public". I'm not
sure what in the document would need to change.

Certainly a protocol that contains an ACL represents the
intent of the sender of the ACL about the access to the
data that is intended to be controlled by that ACL.

In any case, the IETF, when publishing an informational document, does
not "endorse" the document or any IPR rights claimed in it --
in fact, there's a specific disclaimer included:

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

Would you like a specific reference to that disclaimer
in the body of the document?

Larry

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:39 2006
Subject: please review 'application/pdf' -- new version
In-Reply-To: <[email-masked]>
Message-ID: <003b01c3c4c6$5e039e50$6701a8c0@MasinterT40>

> that's certainly better than the original text.  however, I still
don't 
> want IETF endorsing Adobe's insistence that PDF permissions inherently

> reflect the content-owner's intent, nor that viewer authors "must"
take 
> away legitimate rights from those who are reading the documents -
which 
> are not completely the content-owner's to control.
> 
> would you folks please stop trying to screw the public?

Keith,

It's a little hard to work through your conspiracy-theory
approach to the topic. Certainly I can assure you that
there is no intent to "try to screw the public". I'm not
sure what in the document would need to change.

Certainly a protocol that contains an ACL represents the
intent of the sender of the ACL about the access to the
data that is intended to be controlled by that ACL.

In any case, the IETF, when publishing an informational document, does
not "endorse" the document or any IPR rights claimed in it --
in fact, there's a specific disclaimer included:

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

Would you like a specific reference to that disclaimer
in the body of the document?

Larry

From: moore at cs.utk.edu (Keith Moore)
Date: Wed Dec 17 14:49:44 2003
Subject: please review 'application/pdf' -- new version
In-Reply-To: <001a01c3c469$2e7f4a10$6701a8c0@MasinterT40>
References: <001a01c3c469$2e7f4a10$6701a8c0@MasinterT40>
Message-ID: <[email-masked]>

> With regard to Keith's objections about the claims about
> the "document author's copyright", I'm happy to note that
> Adobe has published an errata at
>
>   http://partners.adobe.com/asn/acrobat/sdk/public/docs/errata.txt
>
> which removes the sentence which caused the original complaint;
> the copyright claims in the internet draft were updated to match.

that's certainly better than the original text.  however, I still don't 
want IETF endorsing Adobe's insistence that PDF permissions inherently 
reflect the content-owner's intent, nor that viewer authors "must" take 
away legitimate rights from those who are reading the documents - which 
are not completely the content-owner's to control.

would you folks please stop trying to screw the public?

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:39 2006
Subject: please review 'application/pdf' -- new version
In-Reply-To: <001a01c3c469$2e7f4a10$6701a8c0@MasinterT40>
References: <001a01c3c469$2e7f4a10$6701a8c0@MasinterT40>
Message-ID: <[email-masked]>

> With regard to Keith's objections about the claims about
> the "document author's copyright", I'm happy to note that
> Adobe has published an errata at
>
>   http://partners.adobe.com/asn/acrobat/sdk/public/docs/errata.txt
>
> which removes the sentence which caused the original complaint;
> the copyright claims in the internet draft were updated to match.

that's certainly better than the original text.  however, I still don't 
want IETF endorsing Adobe's insistence that PDF permissions inherently 
reflect the content-owner's intent, nor that viewer authors "must" take 
away legitimate rights from those who are reading the documents - which 
are not completely the content-owner's to control.

would you folks please stop trying to screw the public?

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:39 2006
Subject: please review 'application/pdf' -- new version
In-Reply-To: <[email-masked]>
Message-ID: <001a01c3c469$2e7f4a10$6701a8c0@MasinterT40>

We have just posted 

    draft-zilles-pdf-01.txt

to internet-drafts, so it should appear in a day or two.

In the meanwhile, I also posted a copy to
    http://larry.masinter.net/draft-zilles-pdf-01.txt

There were a number of private comments which caused updates to
several sections (the intro, fragment identifiers section, and
a better description of digital signatures, fixed up references.)
If anyone wants diffs, I'll be happy to send them to you.

With regard to Keith's objections about the claims about
the "document author's copyright", I'm happy to note that
Adobe has published an errata at

  http://partners.adobe.com/asn/acrobat/sdk/public/docs/errata.txt

which removes the sentence which caused the original complaint;
the copyright claims in the internet draft were updated to match.

I believe this draft now addresses all the issues that were raised.

> If Adobe wants to point out that there is such a thing as access
> permissions in PDF, that's merely providing information which
> might be useful to the reader.

Exactly; I believe it meets the criteria for Informational status.

Larry

From: duerst at w3.org (Martin Duerst)
Date: Wed Dec 17 00:19:17 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <1071614605.15819.19.camel@felicia>
References: <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost>
Message-ID: <4.2.0.58.J.20031216180134.06e36e20@localhost>

Hello Linus,

At 23:43 03/12/16 +0100, Linus Walleij wrote:
>tis 2003-12-16 klockan 22.32 skrev Martin Duerst:
>
> > I just by chance realized that you had removed the 'charset'
> > parameter from the registration for application/voicexml+xml,
> > and also for application/ssml+xml. I have found something similar
> > in other recent registration proposals.
>
>Now, wait a second here.
>
>Now there is Martin Duerst from W3.org telling us that we must
>indeed include a "charset" parameter with our foo/bar+xml
>MIME transport types.
>
>Then there is Chris Lilley of the same W3.org telling us *repeatedly*
>to remove it:

First, we are on an IETF list, which means that we are all acting
as concerned individuals, and that we are mainly interested in
getting the best possible solution.

>Now, I've been trusting Chris up til now, simply because he
>represents W3.org.
>
>You are of course welcome to run your internal disputes on the
>issue on these lists if you like, but when you're already at the
>same organizational body, could you *PLEASE* book an internal meeting
>and try to formulate a consensus from the W3.org side on how you
>think this thing should be handled? After all, you invented XML.

Sorry I forgot to mention it, but Chris and me actually had such a
'meeting' last week, and the email I wrote was the result of this
(and a phone call with Max).

Regards,      Martin.
>From [email-masked]  Wed Dec 17 07:44:12 2003
From: LMM at acm.org (Larry Masinter)
Date: Wed Dec 17 07:45:08 2003
Subject: please review 'application/pdf' -- new version
In-Reply-To: <[email-masked]>
Message-ID: <001a01c3c469$2e7f4a10$6701a8c0@MasinterT40>

We have just posted 

    draft-zilles-pdf-01.txt

to internet-drafts, so it should appear in a day or two.

In the meanwhile, I also posted a copy to
    http://larry.masinter.net/draft-zilles-pdf-01.txt

There were a number of private comments which caused updates to
several sections (the intro, fragment identifiers section, and
a better description of digital signatures, fixed up references.)
If anyone wants diffs, I'll be happy to send them to you.

With regard to Keith's objections about the claims about
the "document author's copyright", I'm happy to note that
Adobe has published an errata at

  http://partners.adobe.com/asn/acrobat/sdk/public/docs/errata.txt

which removes the sentence which caused the original complaint;
the copyright claims in the internet draft were updated to match.

I believe this draft now addresses all the issues that were raised.

> If Adobe wants to point out that there is such a thing as access
> permissions in PDF, that's merely providing information which
> might be useful to the reader.

Exactly; I believe it meets the criteria for Informational status.

Larry

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:39 2006
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <1071614605.15819.19.camel@felicia>
References: <4.2.0.58.J.20031216160942.077942a8@localhost> <4.2.0.58.J.20031216160942.077942a8@localhost>
Message-ID: <4.2.0.58.J.20031216180134.06e36e20@localhost>

Hello Linus,

At 23:43 03/12/16 +0100, Linus Walleij wrote:
>tis 2003-12-16 klockan 22.32 skrev Martin Duerst:
>
> > I just by chance realized that you had removed the 'charset'
> > parameter from the registration for application/voicexml+xml,
> > and also for application/ssml+xml. I have found something similar
> > in other recent registration proposals.
>
>Now, wait a second here.
>
>Now there is Martin Duerst from W3.org telling us that we must
>indeed include a "charset" parameter with our foo/bar+xml
>MIME transport types.
>
>Then there is Chris Lilley of the same W3.org telling us *repeatedly*
>to remove it:

First, we are on an IETF list, which means that we are all acting
as concerned individuals, and that we are mainly interested in
getting the best possible solution.

>Now, I've been trusting Chris up til now, simply because he
>represents W3.org.
>
>You are of course welcome to run your internal disputes on the
>issue on these lists if you like, but when you're already at the
>same organizational body, could you *PLEASE* book an internal meeting
>and try to formulate a consensus from the W3.org side on how you
>think this thing should be handled? After all, you invented XML.

Sorry I forgot to mention it, but Chris and me actually had such a
'meeting' last week, and the email I wrote was the result of this
(and a phone call with Max).

Regards,      Martin.

From: triad at df.lth.se (Linus Walleij)
Date: Tue Dec 16 23:43:38 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <4.2.0.58.J.20031216160942.077942a8@localhost>
References: <4.2.0.58.J.20031216160942.077942a8@localhost>
Message-ID: <1071614605.15819.19.camel@felicia>

tis 2003-12-16 klockan 22.32 skrev Martin Duerst:

> I just by chance realized that you had removed the 'charset'
> parameter from the registration for application/voicexml+xml,
> and also for application/ssml+xml. I have found something similar
> in other recent registration proposals.

Now, wait a second here.

Now there is Martin Duerst from W3.org telling us that we must 
indeed include a "charset" parameter with our foo/bar+xml
MIME transport types.

Then there is Chris Lilley of the same W3.org telling us *repeatedly*
to remove it:

> I suggest removing this optional parameter as follows:
>
>     There is no charset parameter. Character handling has identical
>     semantics to the case where the charset parameter of the
>     "application/xml" media type is omitted, as described in
>     [RFC3023].

Now, I've been trusting Chris up til now, simply because he
represents W3.org.

You are of course welcome to run your internal disputes on the
issue on these lists if you like, but when you're already at the
same organizational body, could you *PLEASE* book an internal meeting
and try to formulate a consensus from the W3.org side on how you
think this thing should be handled? After all, you invented XML.

Linus Walleij

From: triad at df.lth.se (Linus Walleij)
Date: Tue Jan  3 16:22:39 2006
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <4.2.0.58.J.20031216160942.077942a8@localhost>
References: <4.2.0.58.J.20031216160942.077942a8@localhost>
Message-ID: <1071614605.15819.19.camel@felicia>

tis 2003-12-16 klockan 22.32 skrev Martin Duerst:

> I just by chance realized that you had removed the 'charset'
> parameter from the registration for application/voicexml+xml,
> and also for application/ssml+xml. I have found something similar
> in other recent registration proposals.

Now, wait a second here.

Now there is Martin Duerst from W3.org telling us that we must 
indeed include a "charset" parameter with our foo/bar+xml
MIME transport types.

Then there is Chris Lilley of the same W3.org telling us *repeatedly*
to remove it:

> I suggest removing this optional parameter as follows:
>
>     There is no charset parameter. Character handling has identical
>     semantics to the case where the charset parameter of the
>     "application/xml" media type is omitted, as described in
>     [RFC3023].

Now, I've been trusting Chris up til now, simply because he
represents W3.org.

You are of course welcome to run your internal disputes on the
issue on these lists if you like, but when you're already at the
same organizational body, could you *PLEASE* book an internal meeting
and try to formulate a consensus from the W3.org side on how you
think this thing should be handled? After all, you invented XML.

Linus Walleij

From: FYergeau at alis.com (Francois Yergeau)
Date: Sun Dec 28 19:33:37 2003
Subject: proposed media type registration: application/voicexml+xml
Message-ID: <[email-masked]>

Seconded, for all the reasons given by Martin. Please restore the charset
parameter.

Regards,

-- 
Fran?ois

> -----Message d'origine-----
> De : Martin Duerst [mailto:[email-masked]]
> Envoy? : 16 d?cembre 2003 16:33
> ? : Max Froumentin; [email-masked]
> Cc : [email-masked]; [email-masked]; Ben Kovitz; Linus
> Walleij
> Objet : Re: proposed media type registration: application/voicexml+xml
> 
> 
> 
> Hello Max, others,
> 
> I just by chance realized that you had removed the 'charset'
> parameter from the registration for application/voicexml+xml,
> and also for application/ssml+xml. I have found something similar
> in other recent registration proposals.
> 
> Here is why I think this is really not a good idea:
> 
> First, we start to get into a patchwork where some types
> allow the 'charset', and others don't. Assuming that there
> is something like generic XML processors (e.g. parsers)
> (which is the whole point of XML), how should such a parser
> know whether the 'charset' parameter is allowed or not,
> and keep up with new registrations?
> 
> Second, there are various scenarios a charset parameter in
> the header is automatically generated, or where it's much
> easier to generate it than to avoid it. The following are
> examples:
> - The classical example of transcoding (converting from one
>    encoding to another). Not very frequent these days on the
>    Web in general, but still used for Russian/Cyrillic encodings
>    and in some mobile phone scenarios.
> - Scripting technologies, for example JSP. With JSP, it is much
>    more straightforward to produce output with the right encoding
>    with a 'charset' parameter in the header than without. The
>    reason for this is that JSP allows to produce any kind of
>    output, not limited to XML, and has to know how to convert
>    from the Java-internal encoding to whatever is used on the
>    wire. Putting that information in the 'charset' parameter
>    in the header then is straightforward; anything else has
>    to be done by hand. Hopefully, excluding certain classes
>    of content production technologies is not what you want.
> - Databases that store content as characters rather than bytes,
>    in a single encoding (in many cases e.g. uniformly UTF-8),
>    and transcode on output. Again, if they use generic technology,
>    getting the 'charset' into the header is much more straightforward
>    than putting it into the body.
> 
> Given all these cases, I think it's not at all appropriate to
> remove the 'charset' parameter from the registration, because
> it would severely limit the use of technology that in good
> faith, and with good reasons, is using it.
> 
> In the long run, I think that an update to RFC 3023 should address
> these issues in more detail to help content producers understand the
> advantages and problems related to charset/encoding information.
> 
> Regards,    Martin.
> 
> 
> At 17:15 03/08/21 +0200, Max Froumentin wrote:
> 
> >Hi,
> >
> >Please consider the attached Internet Draft submission: "The
> >application/voicexml+xml Media Type" (originating from the Voice
> >Browser Working Group of the W3C), for review.
> >
> >Cheers,
> >
> >Max Froumentin, W3C
> 
>From [email-masked]  Sun Dec 28 20:30:43 2003
From: ben at morrow.me.uk ([email-masked])
Date: Sun Dec 28 20:31:50 2003
Subject: Request for guidance on MIME and media types
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

At  4pm on 12/12/03 you (Mark Nottingham) wrote:
> Note that a specification is being prepared that allows for 
> the use of a similar "resolve the URI to insert binary 
> characters" idiom in non-SOAP scenarios.  The general 
> technique is documented at [3] under the working title "MTOM 
> Inclusion Format For You (MIFFY)", a title that will almost 
> surely change due to copyright issues.  The proposed 
> application/soap_mtom+xml media type is thus a specific 
> example of the so-called Miffy class of encodings.  We propose 
> that a media type be assigned to each such use of Miffy, with 
> application/soap_mtom+xml being assigned as the name for the 
> application of Miffy to SOAP envelopes.

I entirely agree that a separate MIME type is appropriate; however, I
would suggest a more generic name be used, such as
application/soap+miffy+xml, with +miffy being generally used for
application-of-Miffy-to-foo types.

Ben

-- 
   If you put all the prophets,   |   You'd have so much more reason
   Mystics and saints             |   Than ever was born
   In one room together,          |   Out of all of the conflicts of time.
[email-masked] |----------------+---------------| The Levellers, 'Believers'
>From [email-masked]  Sat Dec  6 21:57:20 2003
From: triad at df.lth.se (Linus Walleij)
Date: Tue Jan  3 16:22:37 2006
Subject: Registration of MIME media type Application/EDI-Tradacoms
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <1070744239.16581.56.camel@felicia>

m?n 2003-11-17 klockan 09.37 skrev Kyle Meadors:
 
>      MIME subtype name: IETF Tree - EDI-Tradacoms
(...)
>      Published specification: Refer to RFC 1767

First, MIME transport types are lowercase as in "edi-tradacoms"

Obviously there is some difference between "edi-tradacoms" and
what is already in RFC 1767. If you want a registration in the
IETF tree, then write an amendment RFC as well, or the registration
will be ambiguous.

If this is only in use by your company, consider using the vnd.
namespace.

Linus Walleij

From: FYergeau at alis.com (Francois Yergeau)
Date: Tue Jan  3 16:22:39 2006
Subject: proposed media type registration: application/voicexml+xml
Message-ID: <[email-masked]>

Seconded, for all the reasons given by Martin. Please restore the charset
parameter.

Regards,

-- 
Fran?ois

> -----Message d'origine-----
> De : Martin Duerst [mailto:[email-masked]]
> Envoy? : 16 d?cembre 2003 16:33
> ? : Max Froumentin; [email-masked]
> Cc : [email-masked]; [email-masked]; Ben Kovitz; Linus
> Walleij
> Objet : Re: proposed media type registration: application/voicexml+xml
> 
> 
> 
> Hello Max, others,
> 
> I just by chance realized that you had removed the 'charset'
> parameter from the registration for application/voicexml+xml,
> and also for application/ssml+xml. I have found something similar
> in other recent registration proposals.
> 
> Here is why I think this is really not a good idea:
> 
> First, we start to get into a patchwork where some types
> allow the 'charset', and others don't. Assuming that there
> is something like generic XML processors (e.g. parsers)
> (which is the whole point of XML), how should such a parser
> know whether the 'charset' parameter is allowed or not,
> and keep up with new registrations?
> 
> Second, there are various scenarios a charset parameter in
> the header is automatically generated, or where it's much
> easier to generate it than to avoid it. The following are
> examples:
> - The classical example of transcoding (converting from one
>    encoding to another). Not very frequent these days on the
>    Web in general, but still used for Russian/Cyrillic encodings
>    and in some mobile phone scenarios.
> - Scripting technologies, for example JSP. With JSP, it is much
>    more straightforward to produce output with the right encoding
>    with a 'charset' parameter in the header than without. The
>    reason for this is that JSP allows to produce any kind of
>    output, not limited to XML, and has to know how to convert
>    from the Java-internal encoding to whatever is used on the
>    wire. Putting that information in the 'charset' parameter
>    in the header then is straightforward; anything else has
>    to be done by hand. Hopefully, excluding certain classes
>    of content production technologies is not what you want.
> - Databases that store content as characters rather than bytes,
>    in a single encoding (in many cases e.g. uniformly UTF-8),
>    and transcode on output. Again, if they use generic technology,
>    getting the 'charset' into the header is much more straightforward
>    than putting it into the body.
> 
> Given all these cases, I think it's not at all appropriate to
> remove the 'charset' parameter from the registration, because
> it would severely limit the use of technology that in good
> faith, and with good reasons, is using it.
> 
> In the long run, I think that an update to RFC 3023 should address
> these issues in more detail to help content producers understand the
> advantages and problems related to charset/encoding information.
> 
> Regards,    Martin.
> 
> 
> At 17:15 03/08/21 +0200, Max Froumentin wrote:
> 
> >Hi,
> >
> >Please consider the attached Internet Draft submission: "The
> >application/voicexml+xml Media Type" (originating from the Voice
> >Browser Working Group of the W3C), for review.
> >
> >Cheers,
> >
> >Max Froumentin, W3C
> 

From: mark.nottingham at bea.com (Mark Nottingham)
Date: Tue Jan  3 16:22:39 2006
Subject: Request for guidance on MIME and media types
Message-ID: <[email-masked]>

The W3C XML Protocol Working Group is currently working on the Message 
Transmission Optimisation Mechanism (MTOM)[1], which allows more 
efficient transmission of SOAP envelopes [2] by changing their 
on-the-wire XML serialisation.

Registration of the "application/soap+xml" media type is currently 
under way, so that SOAP envelopes (i.e. the XML construct that SOAP 
defines) can be identified in MIME and MIME-like systems. We anticipate 
the need to likewise identify MTOM messages in these systems, and would 
like to solicit guidance about the best way to do so.

Whereas the XML 1.0 serialisation of SOAP is self-contained, MTOM 
serialisation will only use XML for a subset of the envelope data. 
Other portions of the envelope will be transmitted in separate binary 
entities, typically but not necessarily in a multipart/related MIME 
message, and those entities will be referenced with URIs from the 
envelope (which, when using multipart/related, would reside in the root 
part).

A simplistic example might be;

---8<---
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; 
type=application/soap_mtom+xml;
         start="<[email-masked]>"

--MIME_boundary
Content-Type: application/soap_mtom+xml
Content-Transfer-Encoding: 8bit
Content-ID: <[email-masked]>

<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="...">
<SOAP-ENV:Body>
   <!--- xml content here -->
   <Image type="image/jpeg"><Include xmlns="..."
     href="cid:[email-masked]"/></Image>
   <!--- xml content here -->
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <[email-masked]>

[binary image]
--MIME_boundary--
---8<---

Which could be transformed to this XML -

---8<---
<?xml version='1.0' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="...">
<SOAP-ENV:Body>
   <!--- xml content here -->
   <Image type="image/jpeg">[base64-encoded image]</Image>
   <!--- xml content here -->
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
---8<---

The XML that is transmitted by MTOM is thus distinct from 
application/soap+xml in at least the following respects:

* It contains some but not all of the envelope data. Indeed, in the 
common case where multipart MIME is used, it's the entire package that 
conveys the same information as application/soap+xml.

* Its semantics are different from those of a SOAP envelope. The usual 
semantic for a SOAP envelope is to apply the SOAP processing model; the 
semantics of an MTOM envelope are to to resolve the link URIs to create 
a new Infoset, which is in turn processable by the SOAP model.

Therefore, it appears that the application/soap+xml media type, as 
currently defined, is not appropriate to describe the XML format 
created by MTOM.

We've considered several possible alternatives, including 1) use of a 
HTTP content-coding (which we rejected, both because content-codings 
are a HTTP-specific mechanism, whereas we intend to use this encoding 
in other protocols, possibly including MIME-based protocols, and 
because doing so would require labelling the HTTP entity with an 
"application/soap+xml" media type, which would mask the presence of 
multipart MIME), and 2) a MIME content-transfer-encoding (which we 
rejected because registration of new CTEs is discouraged by RFC2045).

Therefore, we believe that it would be most suitable to register a new 
media type, e.g., "application/soap_mtom+xml". This media type would 
identify the XML pre-MTOM processing (i.e., with the URIs to be 
referenced still embedded), possibly (but not necessarily) located 
inside a multipart/related package.

Note that a specification is being prepared that allows for the use of 
a similar "resolve the URI to insert binary characters" idiom in 
non-SOAP scenarios.  The general technique is documented at [3] under 
the working title "MTOM Inclusion Format For You (MIFFY)", a title that 
will almost surely change due to copyright issues.  The proposed 
application/soap_mtom+xml media type is thus a specific example of the 
so-called Miffy class of encodings.  We propose that a media type be 
assigned to each such use of Miffy, with application/soap_mtom+xml 
being assigned as the name for the application of Miffy to SOAP 
envelopes.

We would appreciate any input as to whether this is the most 
appropriate way to flag the use of an alternate serialisation of an XML 
format in MIME, and/or pointers to guidance on this matter.

1. http://www.w3.org/TR/soap12-mtom/
2. http://www.w3.org/TR/soap12-part0/
3. http://www.w3.org/mid/[email-masked]

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

From: mf at w3.org (Max Froumentin)
Date: Wed Dec 10 15:57:01 2003
Subject: proposed media type registration: application/voicexml+xml
Message-ID: <[email-masked]>

Hi,

Please consider the attached Internet Draft submission: "The
application/voicexml+xml Media Type" (originating from the Voice
Browser Working Group of the W3C), for review.

Cheers,

Max Froumentin, W3C

-------------- next part --------------
Network Working Group	                                     M. Froumentin
INTERNET DRAFT                                                         W3C
draft-froumentin-voicexml-media-type-01.txt                  December 2003

       The application/voicexml+xml Media Type

Status of this Memo

     This document is anhttp://www.ietf.org/rfc/rfc2026.txt
     Internet-Draft and is subject to all provisions of Section 10 of
     RFC2026.  http://www.ietf.org/rfc/rfc2026.txt 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
     ashttp://www.ietf.org/rfc/rfc2026.txt 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/1id-abstracts.html

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

Abstract

   This document specifies the Media Type for the W3C Voice Extensible
   Markup Language (VoiceXML), version 2.0. VoiceXML is an XML markup
   language designed for creating audio dialogs that feature
   synthesized speech, digitized audio, recognition of spoken and DTMF
   key input, recording of spoken input, telephony, and
   mixed-initiative conversations.

Expires: June 2004

1.  Introduction

   The World Wide Web Consortium has issued a specification [VXML]
   defining the Voice Extensible Markup Language (VoiceXML), version
   2.0. This memo provides information about the
   application/voicexml+xml Media Type, intended to be used for
   transferring VoiceXML documents.

   This document follows the convention set out in [XMLMIME] for the
   MIME subtype name; attaching the suffix "+xml" to denote that the
   entity being described conforms to the XML syntax as defined in XML
   1.0 [XML].

   This document was prepared by members of the W3C Voice Browser
   working group.  Please send comments to [email-masked], a public
   mailing list with archives at
   <http://lists.w3.org/Archives/Public/www-voice/>.

2. Registration of MIME media type application/voicexml+xml

    MIME media type name:      application
    MIME subtype name:         voicexml+xml
    Required parameters:       none
    Optional parameters:       none

   Encoding considerations:
      See Section 4 of this document.

   Security considerations:
      See Section 7 of this document.

   Interoperability considerations:
      VoiceXML [VXML] specifies user agent conformance rules that
      dictate behaviour that must be followed when dealing with, among
      other things, unrecognized elements.

   Published specification:
      VoiceXML 2.0 is now defined as a W3C Recommendation; the latest
      published versions is at [VoiceXML].

   Applications which use this media type:
      Some content authors have already begun hand and tool authoring
      on the Web with VoiceXML.  However that content is currently
      described as "text/xml" or "application/xml", allowing existing
      Web browsers to process it without reconfiguration for a new
      media type.

      This new type is being registered in order to allow for the
      expected deployment of VoiceXML on the World Wide Web, as a first
      class XML application where authors can expect that user agents
      are conformant XML 1.0 [XML] processors.

   Additional information:

      Magic number:
         There is no single initial byte sequence that is always present
         for VoiceXML files.  However, Section 5 below gives some
         guidelines for recognizing VoiceXML files. See also section 3.1 in
         [XMLMIME].

      File extension:
         There most common file extension that is currently in use
         for VoiceXML is ".vxml".

      Macintosh File Type code: TEXT

   Person & email address to contact for further information:
      Max Froumentin <[email-masked]>

   Intended usage: COMMON

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

3. Encoding considerations

   By virtue of VoiceXML content being XML, it has the same
   considerations when sent as 'application/voicexml+xml' as does XML.
   See [XMLMIME], section 3.2.

4. Recognizing VoiceXML files

   All VoiceXML documents will have the string "<vxml" near the beginning
   of the document.  Some will also begin with an XML declaration which
   begins with "<?xml", though that alone does not indicate a VoiceXML
   document.  

5. Charset default rules

   By virtue of all VoiceXML content being XML, it has the same
   considerations when sent as 'application/voicexml+xml' as does XML
   ([XMLMIME], section 3.2) in the absence of the charset parameter.

6. Security Considerations

   The considerations for 'application/xml' as specified in [XMLMIME],
   also hold for 'application/voicexml+xml'.

   In addition, several VoiceXML instructions may cause arbitrary URIs
   to be dereferenced. In this case, the security issues of RFC1738,
   section 6, should be considered.

   Furthermore, because of the extensibility features that VoiceXML
   defines, it is possible that 'application/voicexml+xml' may describe
   content that has security implications beyond those described here.
   However, if the user agent follows the user agent conformance rules
   in [VXML], this content will be ignored.  Only in the case where
   the user agent 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.

7.  Author's Address

   Max Froumentin
   W3C/ERCIM
   2004, route des Lucioles - B.P. 93
   06902 Sophia Antipolis Cedex
   FRANCE

   Phone: +33 (0)492387889
   Fax:+33 (0)492387822
   EMail: [email-masked]

8.  References

   [VXML] "Voice Extensible Markup Language (VoiceXML) Version 2.0",
          W3C Working Draft (work in progress), October 2001. 
          Available at <http://www.w3.org/TR/voicexml20/>.

   [XML]       "Extensible Markup Language (XML) 1.0", W3C
               Recommendation.  Available at <http://www.w3.org/TR/REC-
               xml> (or <http://www.w3.org/TR/2000/REC-xml-20001006>).

   [XMLMIME]   Murata, M., St.Laurent, S. and D. Kohn, "XML Media
               Types", RFC 3023, January 2001.

10.  Full Copyright Statement

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
>From [email-masked]  Wed Dec 10 17:41:40 2003
From: mf at w3.org (Max Froumentin)
Date: Wed Dec 10 17:41:51 2003
Subject: proposed media type registration: application/ssml+xml
In-Reply-To: <[email-masked]> (Max Froumentin's message of "Thu, 21
	Aug 2003 17:15:04 +0200")
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

Please consider the attached Internet Draft submission: "The
application/ssml+xml Media Type" (originating from the Voice
Browser Working Group of the W3C), for review.

Cheers,

Max Froumentin, W3C

-------------- next part --------------
Network Working Group	                                     M. Froumentin
INTERNET DRAFT                                                         W3C
draft-froumentin-ssml-media-type.txt                         December 2003

       The application/ssml+xml Media Type

Status of this Memo

     This document is anhttp://www.ietf.org/rfc/rfc2026.txt
     Internet-Draft and is subject to all provisions of Section 10 of
     RFC2026.  http://www.ietf.org/rfc/rfc2026.txt 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
     ashttp://www.ietf.org/rfc/rfc2026.txt 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/1id-abstracts.html

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

Abstract

   This document specifies the Media Type for the W3C Speech Synthesis
   Markup Language (SSML). 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 SSML
   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.

Expires: June 2004

1.  Introduction

   The World Wide Web Consortium has issued a specification [SSML]
   defining the Speech Synthesis Markup Language (SSML). This memo
   provides information about the application/ssml+xml Media Type,
   intended to be used for transferring SSML documents.

   This document follows the convention set out in [XMLMIME] for the
   MIME subtype name; attaching the suffix "+xml" to denote that the
   entity being described conforms to the XML syntax as defined in XML
   1.0 [XML].

   This document was prepared by members of the W3C Voice Browser
   working group.  Please send comments to [email-masked], a public
   mailing list with archives at
   <http://lists.w3.org/Archives/Public/www-voice/>.

2. Registration of MIME media type application/ssml+xml

    MIME media type name:      application
    MIME subtype name:         ssml+xml
    Required parameters:       none
    Optional parameters:       none

   Encoding considerations:
      See Section 4 of this document.

   Security considerations:
      See Section 7 of this document.

   Interoperability considerations:
      SSML [SSML] specifies user agent conformance rules that
      dictate behaviour that must be followed when dealing with, among
      other things, unrecognized elements.

   Published specification:
      SSML is now defined as a W3C specification; the latest
      published versions is at [SSML].

   Applications which use this media type:
      Some content authors have already begun hand and tool authoring
      on the Web with SSML.  However that content is currently
      described as "text/xml" or "application/xml", allowing existing
      Web browsers to process it without reconfiguration for a new
      media type.

      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 where authors can expect that user agents
      are conformant XML 1.0 [XML] processors.

   Additional information:

      Magic number:
         There is no single initial byte sequence that is always present
         for SSML files.  However, Section 5 below gives some
         guidelines for recognizing SSML files. See also section 3.1 in
         [XMLMIME].

      File extension:
         There most common file extension that is currently in use
         for SSML is ".ssml".

      Macintosh File Type code: TEXT

   Person & email address to contact for further information:
      Max Froumentin <[email-masked]>

   Intended usage: COMMON

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

3. Encoding considerations

   By virtue of SSML content being XML, it has the same
   considerations when sent as 'application/ssml+xml' as does XML.
   See [XMLMIME], section 3.2.

4. Recognizing SSML files

   All SSML documents will have the string "<speak" near the beginning
   of the document.  Some will also begin with an XML declaration which
   begins with "<?xml", though that alone does not indicate a SSML
   document.  

5. Charset default rules

   By virtue of all SSML content being XML, it has the same
   considerations when sent as 'application/ssml+xml' as does XML
   ([XMLMIME], section 3.2) in the absence of the charset parameter.

6. Security Considerations

   The considerations for 'application/xml' as specified in [XMLMIME],
   also hold for 'application/ssml+xml'.

   In addition, several SSML instructions may cause arbitrary URIs
   to be dereferenced. In this case, the security issues of RFC1738,
   section 6, should be considered.

   Furthermore, because of the extensibility features that SSML
   defines, it is possible that 'application/ssml+xml' may describe
   content that has security implications beyond those described here.
   However, if the user agent follows the user agent conformance rules
   in [SSML], this content will be ignored.  Only in the case where
   the user agent 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.

7.  Author's Address

   Max Froumentin
   W3C/ERCIM
   2004, route des Lucioles - B.P. 93
   06902 Sophia Antipolis Cedex
   FRANCE

   Phone: +33 (0)492387889
   Fax:+33 (0)492387822
   EMail: [email-masked]

8.  References

   [SSML] "Speech Synthesis Markup Language Version 1.0",
          W3C Working Draft (work in progress), December 2002 2001. 
          Available at <http://www.w3.org/TR/speech-synthesis/>.

   [XML]       "Extensible Markup Language (XML) 1.0", W3C
               Recommendation.  Available at <http://www.w3.org/TR/REC-
               xml> (or <http://www.w3.org/TR/2000/REC-xml-20001006>).

   [XMLMIME]   Murata, M., St.Laurent, S. and D. Kohn, "XML Media
               Types", RFC 3023, January 2001.

10.  Full Copyright Statement

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
>From [email-masked]  Tue Dec 16 22:32:59 2003
From: duerst at w3.org (Martin Duerst)
Date: Tue Dec 16 22:34:23 2003
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <[email-masked]>
Message-ID: <4.2.0.58.J.20031216160942.077942a8@localhost>

Hello Max, others,

I just by chance realized that you had removed the 'charset'
parameter from the registration for application/voicexml+xml,
and also for application/ssml+xml. I have found something similar
in other recent registration proposals.

Here is why I think this is really not a good idea:

First, we start to get into a patchwork where some types
allow the 'charset', and others don't. Assuming that there
is something like generic XML processors (e.g. parsers)
(which is the whole point of XML), how should such a parser
know whether the 'charset' parameter is allowed or not,
and keep up with new registrations?

Second, there are various scenarios a charset parameter in
the header is automatically generated, or where it's much
easier to generate it than to avoid it. The following are
examples:
- The classical example of transcoding (converting from one
   encoding to another). Not very frequent these days on the
   Web in general, but still used for Russian/Cyrillic encodings
   and in some mobile phone scenarios.
- Scripting technologies, for example JSP. With JSP, it is much
   more straightforward to produce output with the right encoding
   with a 'charset' parameter in the header than without. The
   reason for this is that JSP allows to produce any kind of
   output, not limited to XML, and has to know how to convert
   from the Java-internal encoding to whatever is used on the
   wire. Putting that information in the 'charset' parameter
   in the header then is straightforward; anything else has
   to be done by hand. Hopefully, excluding certain classes
   of content production technologies is not what you want.
- Databases that store content as characters rather than bytes,
   in a single encoding (in many cases e.g. uniformly UTF-8),
   and transcode on output. Again, if they use generic technology,
   getting the 'charset' into the header is much more straightforward
   than putting it into the body.

Given all these cases, I think it's not at all appropriate to
remove the 'charset' parameter from the registration, because
it would severely limit the use of technology that in good
faith, and with good reasons, is using it.

In the long run, I think that an update to RFC 3023 should address
these issues in more detail to help content producers understand the
advantages and problems related to charset/encoding information.

Regards,    Martin.

At 17:15 03/08/21 +0200, Max Froumentin wrote:

>Hi,
>
>Please consider the attached Internet Draft submission: "The
>application/voicexml+xml Media Type" (originating from the Voice
>Browser Working Group of the W3C), for review.
>
>Cheers,
>
>Max Froumentin, W3C

From: mf at w3.org (Max Froumentin)
Date: Tue Jan  3 16:22:38 2006
Subject: proposed media type registration: application/voicexml+xml
Message-ID: <[email-masked]>

Hi,

Please consider the attached Internet Draft submission: "The
application/voicexml+xml Media Type" (originating from the Voice
Browser Working Group of the W3C), for review.

Cheers,

Max Froumentin, W3C

-------------- next part --------------
Network Working Group	                                     M. Froumentin
INTERNET DRAFT                                                         W3C
draft-froumentin-voicexml-media-type-01.txt                  December 2003

       The application/voicexml+xml Media Type

Status of this Memo

     This document is anhttp://www.ietf.org/rfc/rfc2026.txt
     Internet-Draft and is subject to all provisions of Section 10 of
     RFC2026.  http://www.ietf.org/rfc/rfc2026.txt 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
     ashttp://www.ietf.org/rfc/rfc2026.txt 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/1id-abstracts.html

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

Abstract

   This document specifies the Media Type for the W3C Voice Extensible
   Markup Language (VoiceXML), version 2.0. VoiceXML is an XML markup
   language designed for creating audio dialogs that feature
   synthesized speech, digitized audio, recognition of spoken and DTMF
   key input, recording of spoken input, telephony, and
   mixed-initiative conversations.

Expires: June 2004

1.  Introduction

   The World Wide Web Consortium has issued a specification [VXML]
   defining the Voice Extensible Markup Language (VoiceXML), version
   2.0. This memo provides information about the
   application/voicexml+xml Media Type, intended to be used for
   transferring VoiceXML documents.

   This document follows the convention set out in [XMLMIME] for the
   MIME subtype name; attaching the suffix "+xml" to denote that the
   entity being described conforms to the XML syntax as defined in XML
   1.0 [XML].

   This document was prepared by members of the W3C Voice Browser
   working group.  Please send comments to [email-masked], a public
   mailing list with archives at
   <http://lists.w3.org/Archives/Public/www-voice/>.

2. Registration of MIME media type application/voicexml+xml

    MIME media type name:      application
    MIME subtype name:         voicexml+xml
    Required parameters:       none
    Optional parameters:       none

   Encoding considerations:
      See Section 4 of this document.

   Security considerations:
      See Section 7 of this document.

   Interoperability considerations:
      VoiceXML [VXML] specifies user agent conformance rules that
      dictate behaviour that must be followed when dealing with, among
      other things, unrecognized elements.

   Published specification:
      VoiceXML 2.0 is now defined as a W3C Recommendation; the latest
      published versions is at [VoiceXML].

   Applications which use this media type:
      Some content authors have already begun hand and tool authoring
      on the Web with VoiceXML.  However that content is currently
      described as "text/xml" or "application/xml", allowing existing
      Web browsers to process it without reconfiguration for a new
      media type.

      This new type is being registered in order to allow for the
      expected deployment of VoiceXML on the World Wide Web, as a first
      class XML application where authors can expect that user agents
      are conformant XML 1.0 [XML] processors.

   Additional information:

      Magic number:
         There is no single initial byte sequence that is always present
         for VoiceXML files.  However, Section 5 below gives some
         guidelines for recognizing VoiceXML files. See also section 3.1 in
         [XMLMIME].

      File extension:
         There most common file extension that is currently in use
         for VoiceXML is ".vxml".

      Macintosh File Type code: TEXT

   Person & email address to contact for further information:
      Max Froumentin <[email-masked]>

   Intended usage: COMMON

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

3. Encoding considerations

   By virtue of VoiceXML content being XML, it has the same
   considerations when sent as 'application/voicexml+xml' as does XML.
   See [XMLMIME], section 3.2.

4. Recognizing VoiceXML files

   All VoiceXML documents will have the string "<vxml" near the beginning
   of the document.  Some will also begin with an XML declaration which
   begins with "<?xml", though that alone does not indicate a VoiceXML
   document.  

5. Charset default rules

   By virtue of all VoiceXML content being XML, it has the same
   considerations when sent as 'application/voicexml+xml' as does XML
   ([XMLMIME], section 3.2) in the absence of the charset parameter.

6. Security Considerations

   The considerations for 'application/xml' as specified in [XMLMIME],
   also hold for 'application/voicexml+xml'.

   In addition, several VoiceXML instructions may cause arbitrary URIs
   to be dereferenced. In this case, the security issues of RFC1738,
   section 6, should be considered.

   Furthermore, because of the extensibility features that VoiceXML
   defines, it is possible that 'application/voicexml+xml' may describe
   content that has security implications beyond those described here.
   However, if the user agent follows the user agent conformance rules
   in [VXML], this content will be ignored.  Only in the case where
   the user agent 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.

7.  Author's Address

   Max Froumentin
   W3C/ERCIM
   2004, route des Lucioles - B.P. 93
   06902 Sophia Antipolis Cedex
   FRANCE

   Phone: +33 (0)492387889
   Fax:+33 (0)492387822
   EMail: [email-masked]

8.  References

   [VXML] "Voice Extensible Markup Language (VoiceXML) Version 2.0",
          W3C Working Draft (work in progress), October 2001. 
          Available at <http://www.w3.org/TR/voicexml20/>.

   [XML]       "Extensible Markup Language (XML) 1.0", W3C
               Recommendation.  Available at <http://www.w3.org/TR/REC-
               xml> (or <http://www.w3.org/TR/2000/REC-xml-20001006>).

   [XMLMIME]   Murata, M., St.Laurent, S. and D. Kohn, "XML Media
               Types", RFC 3023, January 2001.

10.  Full Copyright Statement

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
>From [email-masked]  Wed Dec 10 17:41:40 2003
From: mf at w3.org (Max Froumentin)
Date: Tue Jan  3 16:22:38 2006
Subject: proposed media type registration: application/ssml+xml
In-Reply-To: <[email-masked]> (Max Froumentin's message of "Thu, 21
	Aug 2003 17:15:04 +0200")
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

Please consider the attached Internet Draft submission: "The
application/ssml+xml Media Type" (originating from the Voice
Browser Working Group of the W3C), for review.

Cheers,

Max Froumentin, W3C

-------------- next part --------------
Network Working Group	                                     M. Froumentin
INTERNET DRAFT                                                         W3C
draft-froumentin-ssml-media-type.txt                         December 2003

       The application/ssml+xml Media Type

Status of this Memo

     This document is anhttp://www.ietf.org/rfc/rfc2026.txt
     Internet-Draft and is subject to all provisions of Section 10 of
     RFC2026.  http://www.ietf.org/rfc/rfc2026.txt 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
     ashttp://www.ietf.org/rfc/rfc2026.txt 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/1id-abstracts.html

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

Abstract

   This document specifies the Media Type for the W3C Speech Synthesis
   Markup Language (SSML). 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 SSML
   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.

Expires: June 2004

1.  Introduction

   The World Wide Web Consortium has issued a specification [SSML]
   defining the Speech Synthesis Markup Language (SSML). This memo
   provides information about the application/ssml+xml Media Type,
   intended to be used for transferring SSML documents.

   This document follows the convention set out in [XMLMIME] for the
   MIME subtype name; attaching the suffix "+xml" to denote that the
   entity being described conforms to the XML syntax as defined in XML
   1.0 [XML].

   This document was prepared by members of the W3C Voice Browser
   working group.  Please send comments to [email-masked], a public
   mailing list with archives at
   <http://lists.w3.org/Archives/Public/www-voice/>.

2. Registration of MIME media type application/ssml+xml

    MIME media type name:      application
    MIME subtype name:         ssml+xml
    Required parameters:       none
    Optional parameters:       none

   Encoding considerations:
      See Section 4 of this document.

   Security considerations:
      See Section 7 of this document.

   Interoperability considerations:
      SSML [SSML] specifies user agent conformance rules that
      dictate behaviour that must be followed when dealing with, among
      other things, unrecognized elements.

   Published specification:
      SSML is now defined as a W3C specification; the latest
      published versions is at [SSML].

   Applications which use this media type:
      Some content authors have already begun hand and tool authoring
      on the Web with SSML.  However that content is currently
      described as "text/xml" or "application/xml", allowing existing
      Web browsers to process it without reconfiguration for a new
      media type.

      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 where authors can expect that user agents
      are conformant XML 1.0 [XML] processors.

   Additional information:

      Magic number:
         There is no single initial byte sequence that is always present
         for SSML files.  However, Section 5 below gives some
         guidelines for recognizing SSML files. See also section 3.1 in
         [XMLMIME].

      File extension:
         There most common file extension that is currently in use
         for SSML is ".ssml".

      Macintosh File Type code: TEXT

   Person & email address to contact for further information:
      Max Froumentin <[email-masked]>

   Intended usage: COMMON

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

3. Encoding considerations

   By virtue of SSML content being XML, it has the same
   considerations when sent as 'application/ssml+xml' as does XML.
   See [XMLMIME], section 3.2.

4. Recognizing SSML files

   All SSML documents will have the string "<speak" near the beginning
   of the document.  Some will also begin with an XML declaration which
   begins with "<?xml", though that alone does not indicate a SSML
   document.  

5. Charset default rules

   By virtue of all SSML content being XML, it has the same
   considerations when sent as 'application/ssml+xml' as does XML
   ([XMLMIME], section 3.2) in the absence of the charset parameter.

6. Security Considerations

   The considerations for 'application/xml' as specified in [XMLMIME],
   also hold for 'application/ssml+xml'.

   In addition, several SSML instructions may cause arbitrary URIs
   to be dereferenced. In this case, the security issues of RFC1738,
   section 6, should be considered.

   Furthermore, because of the extensibility features that SSML
   defines, it is possible that 'application/ssml+xml' may describe
   content that has security implications beyond those described here.
   However, if the user agent follows the user agent conformance rules
   in [SSML], this content will be ignored.  Only in the case where
   the user agent 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.

7.  Author's Address

   Max Froumentin
   W3C/ERCIM
   2004, route des Lucioles - B.P. 93
   06902 Sophia Antipolis Cedex
   FRANCE

   Phone: +33 (0)492387889
   Fax:+33 (0)492387822
   EMail: [email-masked]

8.  References

   [SSML] "Speech Synthesis Markup Language Version 1.0",
          W3C Working Draft (work in progress), December 2002 2001. 
          Available at <http://www.w3.org/TR/speech-synthesis/>.

   [XML]       "Extensible Markup Language (XML) 1.0", W3C
               Recommendation.  Available at <http://www.w3.org/TR/REC-
               xml> (or <http://www.w3.org/TR/2000/REC-xml-20001006>).

   [XMLMIME]   Murata, M., St.Laurent, S. and D. Kohn, "XML Media
               Types", RFC 3023, January 2001.

10.  Full Copyright Statement

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
>From [email-masked]  Tue Dec 16 22:32:59 2003
From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:38 2006
Subject: proposed media type registration: application/voicexml+xml
In-Reply-To: <[email-masked]>
Message-ID: <4.2.0.58.J.20031216160942.077942a8@localhost>

Hello Max, others,

I just by chance realized that you had removed the 'charset'
parameter from the registration for application/voicexml+xml,
and also for application/ssml+xml. I have found something similar
in other recent registration proposals.

Here is why I think this is really not a good idea:

First, we start to get into a patchwork where some types
allow the 'charset', and others don't. Assuming that there
is something like generic XML processors (e.g. parsers)
(which is the whole point of XML), how should such a parser
know whether the 'charset' parameter is allowed or not,
and keep up with new registrations?

Second, there are various scenarios a charset parameter in
the header is automatically generated, or where it's much
easier to generate it than to avoid it. The following are
examples:
- The classical example of transcoding (converting from one
   encoding to another). Not very frequent these days on the
   Web in general, but still used for Russian/Cyrillic encodings
   and in some mobile phone scenarios.
- Scripting technologies, for example JSP. With JSP, it is much
   more straightforward to produce output with the right encoding
   with a 'charset' parameter in the header than without. The
   reason for this is that JSP allows to produce any kind of
   output, not limited to XML, and has to know how to convert
   from the Java-internal encoding to whatever is used on the
   wire. Putting that information in the 'charset' parameter
   in the header then is straightforward; anything else has
   to be done by hand. Hopefully, excluding certain classes
   of content production technologies is not what you want.
- Databases that store content as characters rather than bytes,
   in a single encoding (in many cases e.g. uniformly UTF-8),
   and transcode on output. Again, if they use generic technology,
   getting the 'charset' into the header is much more straightforward
   than putting it into the body.

Given all these cases, I think it's not at all appropriate to
remove the 'charset' parameter from the registration, because
it would severely limit the use of technology that in good
faith, and with good reasons, is using it.

In the long run, I think that an update to RFC 3023 should address
these issues in more detail to help content producers understand the
advantages and problems related to charset/encoding information.

Regards,    Martin.

At 17:15 03/08/21 +0200, Max Froumentin wrote:

>Hi,
>
>Please consider the attached Internet Draft submission: "The
>application/voicexml+xml Media Type" (originating from the Voice
>Browser Working Group of the W3C), for review.
>
>Cheers,
>
>Max Froumentin, W3C

From: moore at cs.utk.edu (Keith Moore)
Date: Mon Dec  8 07:08:57 2003
Subject: please review 'application/pdf'
In-Reply-To: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40>
References: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40>
Message-ID: <[email-masked]>

Larry,

Thinking about this some more -

There are lots of protocols that specify things like access permissions 
- NFS for instance.  We don't have a problem with these.  But we don't 
try to equate NFS permissions with copyright restrictions, nor do we 
threaten NFS implementors whose implementations allow users to ignore 
or circumvent those permissions.  There are several good reasons for 
ignoring or circumventing those permissions, and we don't expect 
computer programs to be able to distinguish the cases where there are 
good reasons from those where the reasons are bad - indeed we cannot 
anticipate all of the good reasons in advance.

In most 2-party protocols we expect 'server' hosts to protect resources 
on those hosts, acting in the interests of the server.  We expect 
client programs to act in the interest of the client, not those of the 
content provider.  We would regard any design that provided a way for 
clients to break access permissions, and merely trusted them not to do 
so, as unsound.  (For instance, this is why use of source port numbers 
< 1024 to prove that you're privileged isn't acceptable.)

Here's how I think this breaks down:

If Adobe wants to point out that there is such a thing as access 
permissions in PDF, that's merely providing information which might be 
useful to the reader.

If Adobe wants to claim that circumventing or ignoring these 
permissions is violating copyright law, that is at best an exaggeration 
and at worst dangerously misleading for a variety of reasons.  IETF 
should not lend its imprimatur to such statements.

If Adobe is going to try to legally screw anyone who implements PDF in 
a way that doesn't enforce access permissions, then giving potential 
implementors warning of that policy in the media type registration is 
in some sense the least Adobe could do.  And if the mechanism by which 
Adobe hopes to screw such implementors is by claiming that the 
implementors are violating their "copyright" on data structures, this 
is pretty similar to reasons that we have IPR statements in other 
documents.   Just as with patent claims, IETF shouldn't make any 
comment on the legal validity of this theory.

But  if Adobe is going to have that policy, I don't think IETF should 
be helping to promote PDF by publishing this as an RFC - the most we 
should do is update the media-type registration.  Furthermore, IETF 
should stop supporting the use of PDF in Internet-Drafts and RFCs, in 
favor of some other format that is freely usable.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:38 2006
Subject: please review 'application/pdf'
In-Reply-To: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40>
References: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40>
Message-ID: <[email-masked]>

Larry,

Thinking about this some more -

There are lots of protocols that specify things like access permissions 
- NFS for instance.  We don't have a problem with these.  But we don't 
try to equate NFS permissions with copyright restrictions, nor do we 
threaten NFS implementors whose implementations allow users to ignore 
or circumvent those permissions.  There are several good reasons for 
ignoring or circumventing those permissions, and we don't expect 
computer programs to be able to distinguish the cases where there are 
good reasons from those where the reasons are bad - indeed we cannot 
anticipate all of the good reasons in advance.

In most 2-party protocols we expect 'server' hosts to protect resources 
on those hosts, acting in the interests of the server.  We expect 
client programs to act in the interest of the client, not those of the 
content provider.  We would regard any design that provided a way for 
clients to break access permissions, and merely trusted them not to do 
so, as unsound.  (For instance, this is why use of source port numbers 
< 1024 to prove that you're privileged isn't acceptable.)

Here's how I think this breaks down:

If Adobe wants to point out that there is such a thing as access 
permissions in PDF, that's merely providing information which might be 
useful to the reader.

If Adobe wants to claim that circumventing or ignoring these 
permissions is violating copyright law, that is at best an exaggeration 
and at worst dangerously misleading for a variety of reasons.  IETF 
should not lend its imprimatur to such statements.

If Adobe is going to try to legally screw anyone who implements PDF in 
a way that doesn't enforce access permissions, then giving potential 
implementors warning of that policy in the media type registration is 
in some sense the least Adobe could do.  And if the mechanism by which 
Adobe hopes to screw such implementors is by claiming that the 
implementors are violating their "copyright" on data structures, this 
is pretty similar to reasons that we have IPR statements in other 
documents.   Just as with patent claims, IETF shouldn't make any 
comment on the legal validity of this theory.

But  if Adobe is going to have that policy, I don't think IETF should 
be helping to promote PDF by publishing this as an RFC - the most we 
should do is update the media-type registration.  Furthermore, IETF 
should stop supporting the use of PDF in Internet-Drafts and RFCs, in 
favor of some other format that is freely usable.

From: moore at cs.utk.edu (Keith Moore)
Date: Mon Dec  8 03:47:32 2003
Subject: please review 'application/pdf'
In-Reply-To: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40>
References: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40>
Message-ID: <[email-masked]>

On Dec 7, 2003, at 8:08 PM, Larry Masinter wrote:

>>> In HTTP, the "cache-control: private" directive is defined
>>> with normative language for HTTP implementations about which
>>> bits they may or may not "share" with other users.
>>
>> clever, but it's not quite the same thing.  cache-control limits what
>> an HTTP intermediary can do with the file, but doesn't place any
>> restrictions on the user.
>
> So you would be satisfied if the document expressed the constraint
> in terms of behavior of the implementations, rather than a constraint
> on the users of those implementations?

no, of course not.  cache-control exists for cache coherency; it 
doesn't limit what the user can do with the file.  however, the 
constraints in PDF are intended to impose restrictions beyond those 
which are supported, and in some cases even beyond those allowed by 
law.  it's trying to replace laws that were crafted as compromises 
between the needs of the public vs. the needs of the content owner, 
with constraints that are solely determined by the creator of the PDF 
file.  that's seriously wrong.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:38 2006
Subject: please review 'application/pdf'
In-Reply-To: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40>
References: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40>
Message-ID: <[email-masked]>

On Dec 7, 2003, at 8:08 PM, Larry Masinter wrote:

>>> In HTTP, the "cache-control: private" directive is defined
>>> with normative language for HTTP implementations about which
>>> bits they may or may not "share" with other users.
>>
>> clever, but it's not quite the same thing.  cache-control limits what
>> an HTTP intermediary can do with the file, but doesn't place any
>> restrictions on the user.
>
> So you would be satisfied if the document expressed the constraint
> in terms of behavior of the implementations, rather than a constraint
> on the users of those implementations?

no, of course not.  cache-control exists for cache coherency; it 
doesn't limit what the user can do with the file.  however, the 
constraints in PDF are intended to impose restrictions beyond those 
which are supported, and in some cases even beyond those allowed by 
law.  it's trying to replace laws that were crafted as compromises 
between the needs of the public vs. the needs of the content owner, 
with constraints that are solely determined by the creator of the PDF 
file.  that's seriously wrong.

From: LMM at acm.org (Larry Masinter)
Date: Mon Dec  8 02:09:10 2003
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
Message-ID: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40>

> > In HTTP, the "cache-control: private" directive is defined
> > with normative language for HTTP implementations about which
> > bits they may or may not "share" with other users.
> 
> clever, but it's not quite the same thing.  cache-control limits what 
> an HTTP intermediary can do with the file, but doesn't place any 
> restrictions on the user.

So you would be satisfied if the document expressed the constraint
in terms of behavior of the implementations, rather than a constraint
on the users of those implementations?

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

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:38 2006
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
Message-ID: <00a101c3bd27$c7d40140$6801a8c0@MasinterT40>

> > In HTTP, the "cache-control: private" directive is defined
> > with normative language for HTTP implementations about which
> > bits they may or may not "share" with other users.
> 
> clever, but it's not quite the same thing.  cache-control limits what 
> an HTTP intermediary can do with the file, but doesn't place any 
> restrictions on the user.

So you would be satisfied if the document expressed the constraint
in terms of behavior of the implementations, rather than a constraint
on the users of those implementations?

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

From: moore at cs.utk.edu (Keith Moore)
Date: Sun Dec  7 16:18:57 2003
Subject: please review 'application/pdf'
In-Reply-To: <000a01c3bc8d$04cf2200$6801a8c0@MasinterT40>
References: <000a01c3bc8d$04cf2200$6801a8c0@MasinterT40>
Message-ID: <[email-masked]>

> In HTTP, the "cache-control: private" directive is defined
> with normative language for HTTP implementations about which
> bits they may or may not "share" with other users.

clever, but it's not quite the same thing.  cache-control limits what 
an HTTP intermediary can do with the file, but doesn't place any 
restrictions on the user.

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:38 2006
Subject: please review 'application/pdf'
In-Reply-To: <000a01c3bc8d$04cf2200$6801a8c0@MasinterT40>
References: <000a01c3bc8d$04cf2200$6801a8c0@MasinterT40>
Message-ID: <[email-masked]>

> In HTTP, the "cache-control: private" directive is defined
> with normative language for HTTP implementations about which
> bits they may or may not "share" with other users.

clever, but it's not quite the same thing.  cache-control limits what 
an HTTP intermediary can do with the file, but doesn't place any 
restrictions on the user.

From: LMM at acm.org (Larry Masinter)
Date: Sun Dec  7 07:41:30 2003
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
Message-ID: <000a01c3bc8d$04cf2200$6801a8c0@MasinterT40>

> > In the end, it's just a file format that includes an
> > some ACL bits. It seems legitimate to describe what
> > ACL bits are intended to mean in a description of
> > a protocol or protocol element or file format,
> > whatever the mechanisms might be for actual enforcement
> > of those bits.
> 
> yup.  just as long as there isn't any statement to the effect that 
> implementations are expected to honor those bits.

In HTTP, the "cache-control: private" directive is defined
with normative language for HTTP implementations about which
bits they may or may not "share" with other users. Shared
cache implementations are expected to honor "cache-control: private";
those that disregard the directive are non-compliant.

Larry

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:38 2006
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
Message-ID: <000a01c3bc8d$04cf2200$6801a8c0@MasinterT40>

> > In the end, it's just a file format that includes an
> > some ACL bits. It seems legitimate to describe what
> > ACL bits are intended to mean in a description of
> > a protocol or protocol element or file format,
> > whatever the mechanisms might be for actual enforcement
> > of those bits.
> 
> yup.  just as long as there isn't any statement to the effect that 
> implementations are expected to honor those bits.

In HTTP, the "cache-control: private" directive is defined
with normative language for HTTP implementations about which
bits they may or may not "share" with other users. Shared
cache implementations are expected to honor "cache-control: private";
those that disregard the directive are non-compliant.

Larry

From: moore at cs.utk.edu (Keith Moore)
Date: Sun Dec  7 04:41:39 2003
Subject: please review 'application/pdf'
In-Reply-To: <000601c3bc73$5eb643d0$6801a8c0@MasinterT40>
References: <000601c3bc73$5eb643d0$6801a8c0@MasinterT40>
Message-ID: <[email-masked]>

> In the end, it's just a file format that includes an
> some ACL bits. It seems legitimate to describe what
> ACL bits are intended to mean in a description of
> a protocol or protocol element or file format,
> whatever the mechanisms might be for actual enforcement
> of those bits.

yup.  just as long as there isn't any statement to the effect that 
implementations are expected to honor those bits.

Keith

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:38 2006
Subject: please review 'application/pdf'
In-Reply-To: <000601c3bc73$5eb643d0$6801a8c0@MasinterT40>
References: <000601c3bc73$5eb643d0$6801a8c0@MasinterT40>
Message-ID: <[email-masked]>

> In the end, it's just a file format that includes an
> some ACL bits. It seems legitimate to describe what
> ACL bits are intended to mean in a description of
> a protocol or protocol element or file format,
> whatever the mechanisms might be for actual enforcement
> of those bits.

yup.  just as long as there isn't any statement to the effect that 
implementations are expected to honor those bits.

Keith

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:38 2006
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
Message-ID: <000601c3bc73$5eb643d0$6801a8c0@MasinterT40>

It's pretty clear that the quoted statement should
be changed in an updated internet draft. It seems
important to make clear that the bits in the file
may be used to specify the creator's intent, but there
is should be no presumption of giving any kind of
legal advice about "rights", whether or not those
rights are related to copyright or any other kind of
right.

In the end, it's just a file format that includes an
some ACL bits. It seems legitimate to describe what
ACL bits are intended to mean in a description of
a protocol or protocol element or file format,
whatever the mechanisms might be for actual enforcement
of those bits.

Larry

From: moore at cs.utk.edu (Keith Moore)
Date: Sun Dec  7 03:53:30 2003
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40> <[email-masked]>
Message-ID: <[email-masked]>

catching up on some very old mail here:

> I also see
> 
>    o Accessing the document in ways not permitted by the document's
>      access permissions is a violation of the document author's
>      copyright.
> 
> This strikes me as a useful statement and I am pleased by its
> inclusion.

I'm going to add my voice to those who believe it's inappropriate for
this statement to be in here.  

* One reason that the statement is inapppropriate is that it's false. *

Copyright, at least in countries that signed Berne convention, assigns certain
discrete rights that are not aligned with the access permissions described in 
a PDF document.  These rights may be assigned exclusively (sold) or
non-exclusively (licensed), and independently of one another.  The fact that
the creator of a PDF document has asserted permissions on the use of that
document should not be taken as prima facia evidence that the owner of the
copyright associated with the  document has assigned the right to the
document's creator to permit such access. In effect, PDF gives the document's
creator the abliity to claim rights (to permit or deny various kinds of access
to the document) that he may not possess.   There is no reason to assume that
the access rights indicated in the PDF document are consistent with the 
rights granted by the copyright holder to the document creator.

Furthermore, in most countries, there are limitations on those rights, both
in that they are time-limited and in that there are exceptions such as for
fair use.  Those limitations vary from one country to another, and are changed
from time to time.  It is not in violation of copyright law for a program to 
permit access that is legally permitted in his jurisdiction, whether this is
because the copyright has expired, or because it falls under fair use, or for
other reasons.

At least in the United States, copyright was intended to strike a balance
between the interests of the public in having works freely available and
the interests in content creators in having an incentive to produce new works.
I've always said that I'll support DRM when it preserves the rights of the
public equally as well as it preserves the rights of the copyright holder,
including the fact that those rights change from one jurisdiction to another
and over time.  PDF doesn't even try to do that - it tries to tip the balance
away from the public.

Frankly, given what is at stake here, I find the effort to get IETF to endorse
this kind of rip off EXTREMELY OFFENSIVE and I will do whatever I can to
encourage IESG and/or the RFC editor to withhold publication, as long as such
offensive statements remain in the document. 

I also find Adobe's claims on copyright of the data structures used in PDF to
be dubious at best, given my understanding of copyright law, and I don't believe
the IETF should lend its imprimatur to such claims.

By introducing DRM into PDF, Adobe has done great harm to the suitability of 
PDF as a document format (particularly for archive purposes), and also to 
the public interest.   IETF should not support this effort.

Keith
>From [email-masked]  Sun Dec  7 04:36:58 2003
From: LMM at acm.org (Larry Masinter)
Date: Sun Dec  7 04:37:22 2003
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
Message-ID: <000601c3bc73$5eb643d0$6801a8c0@MasinterT40>

It's pretty clear that the quoted statement should
be changed in an updated internet draft. It seems
important to make clear that the bits in the file
may be used to specify the creator's intent, but there
is should be no presumption of giving any kind of
legal advice about "rights", whether or not those
rights are related to copyright or any other kind of
right.

In the end, it's just a file format that includes an
some ACL bits. It seems legitimate to describe what
ACL bits are intended to mean in a description of
a protocol or protocol element or file format,
whatever the mechanisms might be for actual enforcement
of those bits.

Larry

From: moore at cs.utk.edu (Keith Moore)
Date: Tue Jan  3 16:22:38 2006
Subject: please review 'application/pdf'
In-Reply-To: <[email-masked]>
References: <000001c399a8$ed849370$c3432099@MasinterT40> <[email-masked]>
Message-ID: <[email-masked]>

catching up on some very old mail here:

> I also see
> 
>    o Accessing the document in ways not permitted by the document's
>      access permissions is a violation of the document author's
>      copyright.
> 
> This strikes me as a useful statement and I am pleased by its
> inclusion.

I'm going to add my voice to those who believe it's inappropriate for
this statement to be in here.  

* One reason that the statement is inapppropriate is that it's false. *

Copyright, at least in countries that signed Berne convention, assigns certain
discrete rights that are not aligned with the access permissions described in 
a PDF document.  These rights may be assigned exclusively (sold) or
non-exclusively (licensed), and independently of one another.  The fact that
the creator of a PDF document has asserted permissions on the use of that
document should not be taken as prima facia evidence that the owner of the
copyright associated with the  document has assigned the right to the
document's creator to permit such access. In effect, PDF gives the document's
creator the abliity to claim rights (to permit or deny various kinds of access
to the document) that he may not possess.   There is no reason to assume that
the access rights indicated in the PDF document are consistent with the 
rights granted by the copyright holder to the document creator.

Furthermore, in most countries, there are limitations on those rights, both
in that they are time-limited and in that there are exceptions such as for
fair use.  Those limitations vary from one country to another, and are changed
from time to time.  It is not in violation of copyright law for a program to 
permit access that is legally permitted in his jurisdiction, whether this is
because the copyright has expired, or because it falls under fair use, or for
other reasons.

At least in the United States, copyright was intended to strike a balance
between the interests of the public in having works freely available and
the interests in content creators in having an incentive to produce new works.
I've always said that I'll support DRM when it preserves the rights of the
public equally as well as it preserves the rights of the copyright holder,
including the fact that those rights change from one jurisdiction to another
and over time.  PDF doesn't even try to do that - it tries to tip the balance
away from the public.

Frankly, given what is at stake here, I find the effort to get IETF to endorse
this kind of rip off EXTREMELY OFFENSIVE and I will do whatever I can to
encourage IESG and/or the RFC editor to withhold publication, as long as such
offensive statements remain in the document. 

I also find Adobe's claims on copyright of the data structures used in PDF to
be dubious at best, given my understanding of copyright law, and I don't believe
the IETF should lend its imprimatur to such claims.

By introducing DRM into PDF, Adobe has done great harm to the suitability of 
PDF as a document format (particularly for archive purposes), and also to 
the public interest.   IETF should not support this effort.

Keith

From: triad at df.lth.se (Linus Walleij)
Date: Sat Dec  6 21:57:32 2003
Subject: Registration of MIME media type Application/EDI-Tradacoms
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <1070744239.16581.56.camel@felicia>

m?n 2003-11-17 klockan 09.37 skrev Kyle Meadors:
 
>      MIME subtype name: IETF Tree - EDI-Tradacoms
(...)
>      Published specification: Refer to RFC 1767

First, MIME transport types are lowercase as in "edi-tradacoms"

Obviously there is some difference between "edi-tradacoms" and
what is already in RFC 1767. If you want a registration in the
IETF tree, then write an amendment RFC as well, or the registration
will be ambiguous.

If this is only in use by your company, consider using the vnd.
namespace.

Linus Walleij