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(_at_)dankohn(_dot_)com>
<http://www.dankohn.com> <tel:+1-650-327-2600>
-----Original Message-----
From: Graham Klyne [mailto:GK(_at_)Dial(_dot_)pipex(_dot_)com]
Sent: Tuesday, 2000-10-17 15:15
To: Dan Kohn
Cc: xml-mime-types(_at_)imc(_dot_)org
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(_at_)ACM(_dot_)ORG)