[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Finishing the XML-tagging discussion



> > > > An advisory parameter of this sort is a worthless parameter. If you cannot
> > > > depend on it appearing for every instance of a given content type you
> > > > cannot use it for anything.
> >
> > > that's not true.   if the parameter is missing then some opportunities
> > > to evaluate the object (in the absence of knowledge of the complete type)
> > > will be lost.  but that's not the same thing as "you cannot use it for
> > > anything".
> >
> > Something that I cannot count on being there is of no use to me, and, I
> > suspect, to anyone else who cares about this stuff. This has to be
> > dependable to be useful.

> by that argument nothing in MIME would be useful except the ability
> to handle text/plain; charset=us-ascii, since that's all that was
> there in RFC 822 and all that could be expected out of email recipients
> at the time MIME was deployed.

That is exactly how I would characterize MIME if it weren't the dominant format
in use today, and the only standardized format for multimedia in RFC822 mail.
Having more than one such format clearly would not be useful. (Indeed, this
exact argument has been used to keep other mechanisms at bay.)

> and I fail to see how special recognition of the -xml frob is any
> more likely than special treatment of a $superclass parameter.
> by your criteria above neither of these will be useful.

It's more likely to work because it's built into the media type, and generation
of correct media types is a solved problem.

> > > how is this kind of "failure" any different than the kind of failure
> > > that exists when a reader doesn't understand image/svg-xml and
> > > fails to recognize that the -xml suffix means that it can be
> > > treated as generic xml?
> >
> > It is different because I can do something about it -- I can upgrade
> > my software. Whereas in order to get benefit from your proposal I have
> > to upgrade the software that created the object I received -- software I
> > do not control. And in some cases I even have to upgrade the protocols
> > in use.

> okay.  I see that there is a higher barrier to adoption of
> $superclass than for -xml because the sender is more likely to
> be able to generate -xml than $superclass.

Finally!

> but I still think you overstate the hazard.  if someone sends you
> an image/svg content without the $superclass label you can still
> fix the problem on your end merely by defining a specific handler
> for image/svg.  true, it doesn't solve the problem for how to deal
> with large numbers of unanticipated XML-based types, but it will
> work on a small scale.

> but I have to wonder - how likely is it that such XML-ish things
> will be generated by vanilla MIME user agents anyway?  isn't it
> more likely that they will be generated by things that are XML-aware?

They will be generated by XML-generation thingies but labelled by 
MIME-generation thingies. I don't have to have a new user agent with
XML-generation capabilities to use XML heavily.

> > Then let's by all means add a content-features tag as well. Negotiation
> > problem solved.

> so you want to put the xml frob in two different places?

I'm not wild about having it in two places either, but we've already accepted
the fact that conneg duplicates a large number of other mechanisms, so this is
in some sense inevitable. For example, content-features potentially duplicates
content-type and accept-features potentially duplicates accept and
accept-charset. (But then again, accept-charset duplicates accept in some
cases.)

I guess my position is that since negotiation facilities came along late in the
game some level of duplication in them is acceptable, and since the handling of
such thing is yet to be coded we can accomodate such duplication as need be.

> seems like that introduces far more silly states than putting
> it in either of them.

On the other hand, there are places where either the content-type or
the features are unavailable.

> banning content negotiation's use of this information hardly seems like a
> constructive way forward.  what I'd like to see is a proposal for  adding
> these frobs that anticipates the needs of content negotiation rather than
> pretending that they don't exist.

> (this can still be done even if they are bundled in the content type name,
> but it it probably needs a slighly different syntax; for one thing,
> "-" already appears in a number of content-type names without being
> intended as a feature separator.)

I actually don't have a problem with this approach either, but it seems
to me it should be part of the content negotiation framework rather than
an isolated, ad-hoc extension to HTTP alone.

> my guess is that superclasses will often be omitted, but will rarely
> be incorrect when they are present.

I'm pretty much convinced this isn't going to be the case. I've seen several
instances of type transformation that are parameter-preserving. We're protected
from this now by the near-orthogonality of media type parameters, but this
would change with a superclass parameter of the sort you propose.

> > No, that is not what I'm saying. What I'm saying is that a new agent, one that
> > depends on the parameter being present, only works if it is present.

> why should an agent depend on the parameter being present (if it knows
> that the specific type is XML-based)?

Keith, you're the one that claims that the instant a new suffix is defined
people will start trying to use it in accept fields, even if such usage
is explicitly disallowed. Whereas all I'm claiming is that people might
just possibly try and use a field we standardize for its intended purpose, and
rely on it when they cannot.

You're the one who's making an apples and oranges argument here.

> > People do expect it. We have argued long and hard that a filename isn't
> > sufficient, and we've mostly won. Now that we've won we want to say,
> > "Surprise, we've changed our minds, you now need to generate these
> > parameters for things to work". This is unacceptable.

> we've always said that the content-type specification included the parameters,
> that the content-type name without the parameters was incomplete.

Unfortunately, while we've won the media type battle, this one we've lost. (It
probably would have helped if we'd had some instances early on where the
parameters were clearly vital in the handling of some atomic type or if we'd
defined the mailcap format so that it was clear that parameters are an
essential part of a media type. Gotta eat your own dog food...)

> so I don't
> see how we're changing our minds by defining new types that happen to have
> parameters - even if some of those parameters are shared with other types.

Basic existentialism here, I'm afraid -- our intentions might have been
good, but they are irrelevant at this point.

> anyway the content negotiation argument isn't about the particular syntax
> that is used. it's about whether, having defined this new frob for
> content-types, we then have to define new content negotiation
> mechanisms to recognize those frobs.  if we can come up with something
> that can be made to more-or-less work with existing HTTP accept and/or
> conneg expressisons, that would seem like a win.

Given the rarity of parameters in accept expresisons, I have to wonder how
well they actually work... 

But in any case, I again repeat that the suffix proposal is not intended
by anybody to be a replacement for the definition of a negotiation mechanism.
If having such a mechanism is a condition of acceptance of the proposal,
I'm sure we can define one that will work.

				Ned