Re: well-formedness error

[Asbjørn Ulsberg <asbjorn@xxxxxxxxxxxxxx>]

On Sun, 20 Jun 2004 09:06:12 +0200, Julian Reschke <julian.reschke@xxxxxx>  
wrote:

> The important thing here is "implementation". From an HTTP protocol  
> point of view, the extension is irrelevant.

Correct.

> So for an IETF protocol that works on top of HTTP, I'd expect it to be
> silent about that topic

Yep.

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

It doesn't work, because the MIME type being served is without the  
'charset' parameter.

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

If you're an administrator with Remote Desktop logon; yes. If you're an  
ordinary user with no Remote Desktop logon, you're basically screwed or  
left with how kind your hosting service is. I think it's an enormous flaw  
in IIS that this even can't be configured at the folder level as Apache  
with .htaccess, but even in Apache, 'AllowOverride' can be set to 'None',  
which renders .htaccess files useless.

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

I'm claiming that 'text/*' binds you to US-ASCII. Is that incorrect?

> "application/..." doesn't have a default encoding.

Ok, so serving '.atom' files as 'application/octet-stream' is OK? This is  
the default content-type on many web-servers for unknown extensions. For  
others it is 'text/plain' which is even worse than 'text/xml'. All of the  
content-types are without 'charset' information.

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

True. I'd still say it's pretty nasty to serve Atom feeds as  
'application/octet-stream'.

> > Yes, that's the whole problem. 'text/*' demands US-ASCII.
>
> ...unless you declare something else.

..Which you can't (in this scenario) because you don't have the rights to  
do so.

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

If you give your feed the name 'atom.xml' it will get served as  
'text/xml'. If you give it the name 'atom.atom' it will either be served  
as 'application/octet-stream' or more likely 'text/plain'. Neither of  
these do anything good imho. They are both worse than charset-less  
'text/plain'.

> Again and again, that's incorrect. The server can be configured to send  
> a custom MIME type (I *did* it, so I know).

I have probably not been clear enough about which users I'm talking about,  
but there are users -- a lot of users -- that have absolutely no way of  
configuring this themselves. If their ISP is kind enough to do this for  
them, they're extremely lucky. Most of them will just say «sorry, we can't  
do that».

It's a really simple solution for Atom: Just exclude these users from the  
target audience. If Atom does this explicitly, we don't have to care about  
them. But if we don't exclude them, we need to do all sorts of research to  
find out if they fit inside the 80/20 rule (which I think will be an  
impossible task) or we will just have to take them in and try to do the  
best possible work for them.

I have to say that I'm not only inclined, but aching to drop these users  
off the train in 90mph. And I hope they hurt themselves in the fall as  
well.

--
Asbjørn Ulsberg         -=|=-        asbjornu@xxxxxxxxxxx
«He's a loathsome offensive brute, yet I can't look away»