RE: XML MIME types draft

Fair point, but we published the draft (and it should have now finished last
call) well before the publication of RFC 2913 (regarding which, congrats).
So, presuming that the IESG decides we have passed Last Call, we will need
to fix in the nest iteration of the standard.

Given that we have 35 references, and there are multi-month latencies built
into the last call and the RFC Editor process, I'm pretty certain we could
never publish without having one of our references grow out of date during
the process.

I expect we will be reissuing the draft before too long anyway, though,
specifically when XBase and XPointer go to W3 Recommendation.  We'll be sure
to fix the conneg references at that time.

Thanks.

                - dan
--
Dan Kohn <mailto:dan@xxxxxxxxxxx>
<http://www.dankohn.com>  <tel:+1-650-327-2600>

-----Original Message-----
From: Graham Klyne [mailto:GK@xxxxxxxxxxxxxx]
Sent: Tuesday, 2000-10-17 15:15
To: Dan Kohn
Cc: xml-mime-types@xxxxxxx
Subject: XML MIME types draft


At 09:17 AM 10/17/00 -0700, you wrote:
>.... Specifically, I would strongly recommend changing your
>application to application/smil+xml, and quoting the appropriate sections
of
>RFC 2376bis by reference rather than by repeating the text.

I noticed this and realized I hadn't checked this draft for some time... 
not since '|xml' was the preferred suffix....

In browsing through, I noticed this:

>A.10 How about using a conneg tag instead (e.g., accept-features:
>      (syntax=xml))?
>
>    When the conneg protocol is fully defined, this may potentially be a
>    reasonable thing to do. But given the limited current state of
>    conneg[RFC2703] development, it is not a credible replacement for a
>    MIME-based solution.
>
>    Also, note that adding a content-type parameter doesn't work with
>    conneg either, since conneg only deals with media types, not their
>    parameters. This is another illustration of the limits of parameters
>    for MIME dispatchers.

While I agree that feature expressions are probably inappropriate for the 
kind of thing you want to do, I disagree with the reasons.

The conneg spec is complete:  RFC2506, RFC 2533, RFC 2912 define the key 
elements here.  All that is missing is a feature tag for expressing XML 
content, and it might be argued that (type='application/xml') could achieve 
that -- see RFC 2913.

I would suggest text something like:

>A.10 How about using a conneg tag instead (e.g., accept-features:
>      (syntax=xml))?
>
>    The conneg framework is designed for use as a protocol element in
>    content negotiation over a broad range of media features.  It's use
>    for simply designating XML formatted data would place an unnecessary
>    processing burden on systems that merely want to
>    invoke generic XML processing where possible.
>
>    For full content negotiation, as opposed to opportunistic XML handling,
>    the +xml convention SHOULD NOT be exploited.  Rather, a mechanism using
>    full content feature description should be employed, such as provided
by
>    RFC 2506, RFC2533, RFC 2912, etc.

#g

------------
Graham Klyne
(GK@xxxxxxx)