Re: well-formedness error

[Julian Reschke <julian.reschke@xxxxxx>]

Asbjørn Ulsberg wrote:

> > Server behaviour that maps file extension to a content type is an  
> > implementation detail.
>
>
> It's not a «detail». It's of major importance. Extension-mapping is the 

The important thing here is "implementation". From an HTTP protocol 
point of view, the extension is irrelevant. So for an IETF protocol that 
works on top of HTTP, I'd expect it to be silent about that topic 
(except maybe for a non-normative "implementation notes" appendix).

> de  facto standard for MIME type serving today. Apache does it. IIS does 
> it.  I'm sure Sun One, WebSphere and others do the same as well.

That's fine. So just use it.

> > The spec should simply state the correct content-type  
> > ("application/...+xml"),
> > that's it.
>
>
> You can't have that content-type on statically served web pages. You 
> just  can't.

That's simply incorrect. "Even" IIS let's you do that.

> > As long as it isn't text/*, that's fine.
>
>
> And then you're stuck with US-ASCII, no matter what the characters in 
> the  XML is encoded with, and no matter what you state in the 
> processing  instruction. Which means that statically served web pages 
> can _only_ be in  english, and never include terms or words from other 
> languages.

Again, that's incorrect. It would really be good if you re-read RFC3023 
before making these claims.

"application/..." doesn't have a default encoding. So XML content served 
as "application/..." simply doesn't have transport-level encoding 
information, and thus you can use any encoding you like, as long as it's 
properly declared in the body.

> > Again, as long as the content isn't served as "text/*", there is no  
> > problem.
>
>
> Yes, that's the whole problem. 'text/*' demands US-ASCII.

...unless you declare something else. Anyway, this is only a problem 
when you use "text/*", so don't do that.

> > Just pick an "application/*" content type and stick with it.
>
>
> We could pick 'julian-and-asbjorn/having-fun-at-the-beach' and it 
> wouldn't  matter. Statically served feeds will either be served as 
> 'text/xml',  'text/plain' or 'application/octet-stream' depending on the 
> feed file's  extension. Which one do you fancy most?

Again and again, that's incorrect. The server can be configured to send 
a custom MIME type (I *did* it, so I know). If you can't get than 
configured (be it because it can't be done technically or because you 
don't have the necessary access rights), that is a shame but that is a 
problem that the Atom spec can't do anything about. Change either the 
server platform or your provider.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760