Re: Proposal for an HTTP ERR method

Disclaimer: I am not a MIME/XML expert.

The problem you seem to be describing is incorrect mapping among
the following three pieces of [mis]information:

	- filename extension
	  (.xml)

which some origin servers [incorrectly] map to:

	- HTTP MIME type/charset
	  (text/xml; implied ascii)

which may not represent:

	- feed MIME type/charset
	  (application/atom+xml(?); possibly not ascii)

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. This
recommendation is likely to be ignored if existing content producers
(and their tools) or consumers (and their tools) prefer .xml
extensions for obvious reasons unrelated to Atom (it is an XML
document, after all).

Other that that, declare the problem out of Atom WG scope. Ignore it.
Work on a general solution outside of the Atom WG, if you think there
is a general solution that will prevent MIME mismatch better than RFC
3023 does. In this context, #4 on your list is not a cure, IMHO. It's
a misapplied bandaid.

HTH,

Alex.


On Thu, 24 Jun 2004, Henry Story wrote:

> Can I turn this round and ask the group how we can deal with the
> following problem?
>
> The Atom group is writing a spec to be used for applications to be
> deployed by the general public. The general public is going to create
> Blog Feeds which are xml and place them on servers. These servers will
> very often have mime types set incorrectly, so that for example xml may
> be served as text/xml even though their encoding is not ascii. Even if
> the feed were served in ascii it seems that text/xml should only allow
> an application to read the data not to process it. Anyway there are a
> huge number of ways things can go wrong in subtle ways. Not only that
> but have found empirically that over 40% of current feeds in the real
> world are already broken.
>
> The xml/http specs combined insist on the importance of refusing to
> parse xml content that is malformed. This I believe is a very important
> requirement. No one wants to go down the complex and tortuous road html
> went down. Indeed that is why xml makes such a strong case for not
> processing malformed content.
>
> We have a specs that insist that one should not do certain things. Yet
> we know that the reality of the world will force feed readers to parse
> such broken xml.
>
> 	1- should we not use xml?
> 	2- should we specifically ignore some RFC as proposed in [1]
>	3- should we make specs that stick to the letter of other
>          RFCs, but are impossible to follow?
> 	4- should we all work together to slightly alter the http and xml
> specs so that breaking the rules are allowed by clients if certain
> appropriate error reporting strategies are attempted?
>
> 	Sincerely,
>
> 		Henry Story
>
> [1] http://intertwingly.net/wiki/pie/PaceShouldBeWellFormed
>
> On 24 Jun 2004, at 17:04, Alex Rousskov wrote:
> >
> > On Thu, 2004-06-24 at 10:16, Henry Story wrote:
> >
> >> 1. There is consensus that automated error notification systems are
> >> needed.
> >
> > On Thu, 24 Jun 2004, Scott Lawrence wrote:
> >
> >> I hear no such consensus.  I certainly am not a part of any such.
> >
> > Ditto. You may face fewer objections if you formulate #1 as
> >
> > 	"some automated error notification systems might be useful in
> > 	some contexts".
> >
> > Alex.
> >
>
>

Received on Thursday, 24 June 2004 15:54:17 UTC