At 01:33 PM 3/20/00 -0500, Keith Moore wrote:
if you want an expression that matches anything ending in -xml,
as far as I can tell, existing http accept header semantics,
and existing conneg expressions, are not sufficient to recognize that.
if you want it to be more general and anticipate the possibility
of multiple frobs (not just -xml) then you need something like
a regular expression matching capability
(so you can look for things like "-xml(-|$)" )
I think we may encountered a problem in our underlying viewpoints. You're
talking about sending */*xml over the wire in headers, while I'm only
talking about using */*xml to recognize XML documents when I get them.
I am talking about both, but I think they're both problems.
or to put it another way, if we're going to invent a new syntatical
convention for describing content-type characteristics, let's
pick one that actually works with content negotiation
rather than one which requires drastic changes to content
negotiation frameworks.
I don't think the proposal as written breaks things any more than
introducing a new MIME type would.
in a sense, it doesn't break anything. in another sense, it
creates a new feature of content-type names that can be exploited,
and people will demand that they be exploited. so it requires
changes of existing implementations. and if the -xml feature catches
on then it will creep into content-type negotiation schemes. this is
not an intended consequence, but it is a likely one.
Compared to the parameter option you keep proposing, I'd say this causes
almost zero problems as far as interoperability and compatibility are
concerned.
interoperability and compatibility aren't as much my concern as
feature creep and its effect on content-negotiation structures.
If user agents start requesting */*xml, we do have a problem.
why do you think they won't want to do that?
However,
that isn't what this I-D proposes - if users find that useful, they'll have
to push for changes in the protocol infrastructure.
yes, but if such changes are to be made, then perhaps it would be a good
idea to pick a syntax for declaring such features that doesn't require
changes to the protocol infrastructure - or at least, to consider what
those infrastructure changes would need to look like and evaluate the
new syntax in light of those changes.
All this suffix does is provide additional information identifying content
as having an XML foundation. I don't believe it has any other
implications, nor do I believe it will interfere with other developing
standards for content negotiation.
and yet you just admitted that it would cause a problem if user agents
started requesting */*xml.
Keith