Subject: RE: Proposal for an HTTP ERR method

From: "Dare Obasanjo" <[email-masked]>
Date: Thu, 24 Jun 2004 16:58:26 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alex Rousskov
> Sent: Thursday, June 24, 2004 12:54 PM
> To: Henry Story
> Cc: [email-masked]; Atom Syntax
> Subject: Re: Proposal for an HTTP ERR method
> 
> Atom WG cannot solve the problem in the middle of the above 
> chain. You can recommend that atom+xml resources do not use 
> .xml extension if possible; you may recommend .atom extension 
> where applicable. 

How does recommending a file extension actually solve the problem?
Specifically how does it solve the problem any better than just
recommending a MIME type? 

Basically I agree with Mark, recommending a file extension makes things
worse not better. But I'd be interested in any counterarguments that
prove this statement wrong.

--
PITHY WORDS OF WISDOM 
It takes about a week of treatment to cure a cold. Without treatment, it
takes seven days.        

This posting is provided "AS IS" with no warranties, and confers no
rights.

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 25 Jun 2004 02:02:54 +0100

> recommending a MIME type? 

They're expecting these files to be served on mis-configured servers
(like apparently a lot of similar files are now).

A mis-configured server which sees .xml will, apparently, tend to call
it text/xml.  (That's silly as application/xml is the only thing that
makes sense as a HTTP server default for .xml files).

(Though, frankly, text/xml with no charset modifier should never have
meant "us-ascii" overriding the <?xml..?> declaration -- that's just
silly.  text/html doesn't force us-ascii interpretation, so the
text/xml meaning isn't even consistent with other text/* types).

A mis-configured server serving .atom will, presumably, either omit
the content-type altogether or pick a useless default like
application/octet-stream.

Clients, as we know (ahem, Microsoft), ignore application/octet-stream
and look at the URL extension in that case.

So they'll interpret the .atom file correctly. :)

That's much better than clients looking in the <?xml..?> declaration
for the character encoding, when they've been told it's text/xml,
isn't it? :) :)

To be fair, a lot of web servers provide no practical way, or no easy
way, to get the content-type set for .xml files to one thing for some
kinds of XML and another thing for other kinds of XML.

Nonethless, I suspect the correct fix in _this_ case is to change the
standards to admit that text/xml (with no charset) doesn't force a
us-ascii charset, because that's silly, and if an XML file starts with
an <?xml..?> declaration which specifies the encoding, _that's_ the
encoding of the file.  Just like text/html.

-- Jamie

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 25 Jun 2004 08:01:57 +0200

> encoding of the file.  Just like text/html.

Absolutely. That makes the most sense, especially since that's how many  
(most?) XML libraries already behave. Therefore, I think Mark's  
PaceShouldBeWellFormed[1] is imho a perfect solution.

____
[1] <url: http://www.intertwingly.net/wiki/pie/PaceShouldBeWellFormed>

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 25 Jun 2004 10:32:04 -0600 (MDT)

> How does recommending a file extension actually solve the problem?

I think Jamie Lokier already explained that. A different extension
prevents origin servers from specifying misleading MIME type or, more
precisely, a MIME type with possibly incorrect (default) charset. See
the elements in the problem "chain" in my original e-mail.

Also, please note that I did not claim that something can solve the
problem.

> recommending a MIME type?

You will need to define your criteria of goodness for me to answer
this question. One difference between extension-based and
MIME-recommendation-based approach is that extension-based approach
works with existing origin servers. Another difference is that it does
not violate existing RFCs.

HTH,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 25 Jun 2004 10:35:42 -0600 (MDT)

On Fri, 25 Jun 2004, [iso-8859-1] Asbjørn Ulsberg wrote:

> Absolutely. That makes the most sense, especially since that's how
> many (most?) XML libraries already behave.

Have you read the arguments for ascii charset default in RFC 3023?
If those arguments are not correct, then somebody should consider
writing an RFC that obsoletes RFC 3023. If those arguments are
correct, then violating the RFC may not be such a good idea even if it
seems to solve the Atom problem.

Alex.

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 25 Jun 2004 18:18:07 +0100

> seems to solve the Atom problem.

RFC 3023:

    Conformant with [RFC2046], if a text/xml entity is received with
    the charset parameter omitted, MIME processors and XML processors
    MUST use the default charset value of "us-ascii"[ASCII].  In cases
    where the XML MIME entity is transmitted via HTTP, the default
    charset value is still "us-ascii".  (Note: There is an
    inconsistency between this specification and HTTP/1.1, which uses
    ISO-8859-1[ISO8859] as the default for a historical reason.  Since
    XML is a new format, a new default should be chosen for better
    I18N.  US-ASCII was chosen, since it is the intersection of UTF-8
    and ISO-8859-1 and since it is already used by MIME.)

Note the inconsistency mentioned.

There is a second inconsistency, which I don't see mentioned in RFC 3023.
>From the HTML 4.01 standard:

    The HTTP protocol ([RFC2616], section 3.7.1) mentions ISO-8859-1
    as a default character encoding when the "charset" parameter is
    absent from the "Content-Type" header field. In practice, this
    recommendation has proved useless because some servers don't allow
    a "charset" parameter to be sent, and others may not be configured
    to send the parameter. Therefore, user agents must not assume any
    default value for the "charset" parameter.

The inconsistency between HTML 4.01 and RFC 3023 is that "text/html"
does _not_ force the document to be interpreted in a particular
charset -- it leaves the client to decide based on the content.  In
this regard, HTML 4.01 overrides RFC 2616.

Whereas, RFC 3023 would like that "text/xml" _does_ the documented to
be interpreted in us-ascii.  This makes complete sense for MIME, where
it really does have to be text.

I don't have a position either way.  I suggest that if RFC 3023 should
be obsoleted, it is should be only if there's an abundance of clients
which look at the <?xml...?> declaration given "text/xml" -- in
effect, giving up a requirement of RFC 3032, in the same way that HTML
4.01 says to give up a requirement from RFC 2616.

I don't know if there is an abundance of such clients.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 25 Jun 2004 18:26:30 +0100

> I don't know if there is an abundance of such clients.

Btw, if I were writing a new client, prior to this thread I would have
made it interpret "text/xml" as meaning to look in the XML declaration
for the charset.

Not out of maliciousness, but ignorance: it had simply never occurred
to me that "text/xml" meant the same as "text/xml; charset=us-ascii".
I've read the XML 1.0 documentation quite closely, and I still managed
to skip over that bit.  I.e. I didn't read RFC 2376 properly which it
references, because it didn't occur to me it was important in this regard.

It's also a bit counterintuitive that an XML file which specifies a
charset in its XML declaration would have one meaning when received as
"text/xml", and another when saved as file.xml and then read again.
Even on a filesystem which saves the content-type as a special
attribute, that's the case, as XML 1.0 says:

   In the interests of interoperability, however, the following rule is
   recommended.  If an XML entity is in a file, the Byte-Order Mark and
   encoding declaration are used (if present) to determine the character
   encoding.

-- Jamie