Re: [Minutes] 20 Oct 2003 TAG teleconf (abstractComponentRefs-37, URI Syntax, RFC 3023)

On Friday, October 24, 2003, 2:24:33 AM, MURATA wrote:


MM> I wrote:

MM> 	The outcome is not clear yet, but I think that we can make
MM> 	some progress.  We can deprecate text/xml.  The use of the
MM> 	charset parameter of application/xml is recommended if and
MM> 	only if the value is correct.

MM> In the XML CG telecon, Chris correctly said 

MM> 	...Editors have been contacted and are agreeable....

MM> http://lists.w3.org/Archives/Member/w3c-xml-cg/2003Oct/0021.html

MM> Thus, the minutes of the TAG is a surprise to me.

MM> I do not know what will the planned I-D say.

Nor do I, in detail, which is why my action was to run it by the TAG
first before it goes to this list before it becomes an internet draft.

As a first cut though it would do what you said above:

- deprecate text/xml.
- the optianal charset parameter of application/xml
  (and non-text/*+xml) is recommended if and
  only if the value is correct.

MM>  If it says "Use the
MM> charset parameter only if it is absolutely correct" and change
MM> "STRONGLY RECOMMENDED" to "RECOMMENDED", then I agree and suppose that
MM> nobody disagree.

That is useful information.

Based on my recent postings on ietf-types, which I am aware that you
follow, you will understand that my position for application/xml and
for the +xml Media types is:

- if people have done the work and plan to support multiple encodings,
and are aware of the risks (non-well-formed files looking like XML on
the server, need to rewrite XML files when saving locally,
difficulties of deploying content when the server is not known, etc)
then sure, go ahead and use the optional charset parameter in the
Media Type registration. I will probably still ask (at least for W3C
specs) whether the test suite included examples where the charset
differed from that of the XML encoding declaration and whether there
is demonstrated interoperability.

- if they are not, then (in accordance with RFC 3023) the optional
charset parameter should not be used and the encoding should be
determined just like RFC 3023 says it should be in the absence of a
charset parameter on non-text/* types.

MM> If it drops the charset parameter, I think that the TAG is running
MM> the risk of ignoring the I18N WG and the IETF-XML-MIME ML, and
MM> breaking implementations of SOAP.

(I was *on* the IETF-XML-MIME ML)

I wonder why you think I have a vested interest in breaking existing
SOAP implementations; you have suggested it twice in the past 24
hours. I don't see any evidence that would support this. In fact, I
don't see any evidence for the TAG wanting to revise any existing
registrations at all.

Suggesting that new registrations do not blindly adopt this parameter
without thinking through the benefits and drawbacks, as I have been
doing, seems like a service to the community.

Nobody is helped by "well we stuck in this parameter because it seemed
like you were supposed to, but of course none of the implementations
actually use it".

-- 
 Chris                            mailto:chris@w3.org

Received on Thursday, 23 October 2003 22:39:11 UTC