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

Re: Finishing the XML-tagging discussion



> > > > Second, the definition of a global parameter namespace is far from the worst
> > > > thing about this. The biggest problem this approach has is that now you have
> > > > what amounts to a mandatory parameter, one which has to appear with every
> > > > appearance of a given media type and must have a specific value in those
> > > > cases.
> >
> > > actually, I don't view the parameter as mandatory; I view it as advisory.
> > > The right way to handle this is to treat it as an image/svg.  Depending
> > > on how you look at it, the information in the $superclass parameter is
> > > either a fallback way to handle the type if you don't know how to handle
> > > image/svg, or additional information that can be used by generic "index
> > > everything that is XML" processors.
> >
> > 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.

> > (Or worse, you will use it and fail when it isn't present.)

> 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.

> > > > This is completely contrary to the entire intent of the parameter
> > > > space: Parameters were intended to convey information that isn't
> > > > invariant with the media type.
> >
> > > it's true that parameters were intended to convey type-specific information,
> > > but I don't see the harm in defining another set of parameters (disjoint
> > > from the type-specific parameters), which convey other information about
> > > the media type.
> >
> > Well, all I can say is that I do see the potential for tremendous harm in
> > doing it, many times more harm than I see in the suffix that you seem to
> > think is so bad.

> again, a concrete example would help.
 
I gave you three.

> > In order for this to be useful they have to affect every agent.

> again, how is this different than the -xml convention?

I've explained the differences repeatedly. I'm not going to do it again.

> > This is a complete red herring. Nobody is proposing that the suffix be
> > used for negotiation purposes. Negotiation is a different problem than
> > labelling.

> yes, they are different problems, but if we establish this syntatic
> conventntion, people will want to use that convention in content
> negotiation.  or to put it another way, a content-type feature
> labelling convention  that works hand in hand with content negotiation
> is vastly more useful than one which does not.

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

> > Again, an advisory parameter of this sort accomplishes nothing.

> "nothing" seems to me like a gross exaggeration.

I see it as an understatement.

> > > To put it another way, if it's absolutely important that every instance
> > > of image/svg be externally labelled as XML then I'd agree with you.
> > > But I don't see this as absolutely important.

> > I do.

> okay, why?

Because I like to build software that actually works most of the time.

> > > > In summary, what this amounts to is nothing less that a complete
> > > > redesign of how  MIME works.
> >
> > > "complete redesign" seems a bit overstated.  It is a slightly different
> > > way of using parameters than originally envisioned.  But it doesn't
> > > interfere with the existing parameter space.
> >
> > Actually, I think I seriously understated it. It isn't just a complete
> > redesign, it is a revamping of the underlying principles and agreements
> > MIME is based on.

> I don't see how reserving a space of parameter names across the board
> amounts to a revamping of these underlying principles.

> (to clarify: I did not intend that such parameters would automagically
> apply to all content-types, but rather, that such names would be
> reserved, much as "charset" is reserved for text/* types.
> so that if a parameter with a reserved name were defined for
> a content-type its use would have to be consistent with the use
> already established for the reserved parameter name).

> > > And while I understand that many implementations don't have the ability
> > > to generate or the ability to interpret content-type parameters, I don't
> > > see how this breaks anything that works now.  by contrast, the -xml frob
> > > coupled with the desire for content-negotiation languages (http accept
> > > and conneg) to recognize anything that is XML does break things.
> > > I'm just trying to minimize breakage.
> >
> > Please cite a single, solitary example of where it breaks things. I'd like
> > to hear of one.

> okay, how many HTTP servers can deal with

> Accept: */*-xml

Any compliant HTTP server can deal with it. Now, it may not give you  the
result you want, but so what? This is nothing but a strawman argument; the
proposal at hand doesn't specify any extensions to the accept field in HTTP. If
you think it is such a risk that such usage will appear then we can
specifically ban it.

> > Thus far all you have cited are easily surmountable
> > problems, like the ordering of future additional suffixes (assuming there
> > ever are any).

> yes, if we decide to use frobs on the content-type name it's not too
> difficult to define a canonical ordering such that there's one unique
> way of spelling any content-type name.  but if we do go in that direction
> then I'd like us to go ahead and define that syntatic convention,
> including the ordering

Fine with me.

> > > a concrete example of something that this breaks would be helpful
> > > in getting me to understand your concerns.
> >
> > It breaks so many things in so many ways... Some exmaples:
> >
> > (1) Silly state problems. Consider the possible effect of image/jpeg;
> >     $superclass=text/xml on a handler only prepared to accept XML text.
> >     (And compare it with the effect of image/jpeg; charset=us-ascii on
> >     any existing handler.)

> we need to compare apples to apples.  if the handler is only prepared
> to accept XML text and the image/jpeg arrives with a $superclass=text/xml
> type then it gets handled to the XML layer and that layer says
> "invalid XML content" (and ideally the recipient gets a chance to save it).
> if it sees image/jpeg; charset=us-ascii then it gets treated as
> application/octet-stream and the recipient gets a chance to save it.

I'm sorry, but I _am_ comparing apples with apples. I've seen way too much
software that simply crashes under such circumstances. (And so, I suspect, have
you.) Whereas the latter case causes no harm at all.

> > (2) Problems with sending agents not including the tag. Suppose an application
> >     is deployed that depends on the superclass tag. (This is inevitable once
> >     the tag is defined, you can call it advisory until you are blue in the
> >     face but if it is used at all it won't be taken as such.)

> let me see if I understand you correctly: what you are saying is that
> people will expect the new convention (whatever it is) to work and
> control the recipient's MIME readers's fallback behavior even in
> the presence of a  vast installed base that neither understands this
> convention nor XML?

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. And this
then implies that a substantial number of agents need to send the tag in order
for it to be useful. This won't happen soon if at all, so my agent that I wrote
which depends on the tag we've called for ends up not working.

> or that this would be like the user agents that could recognize
> filename suffixes but refused  to look at the content-type?
> people would expect their content to be read by the recipient
> even if they could not label it correctly?

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.

> (the latter strikes me as an argment against any sort of XML
> convention at all - since you seem to be saying that if the convention
> does exist that it will be (mis)used in preference to the primary
> content-type )

The nice thing about the tag being part of the media type is that it leverages
off of our years of insisting that proper media type labels be used. We define
the convention and the rest of the problem takes care of itself.

> and how many user agents does this affect?  e.g., what percentage
> of UAs cannot send out a text/plain attachment with a charset label?

A pretty large number, actually.

> > (3) Problems with places where parameters aren't expected/allowed. Once
> >     the tag is required there will be pressure to generate it. This in turn
> >     will lead to sending agents upgrading producing it and thereby cranking
> >     out parameters for the first time. Some of these agents are now used to
> >     generate values for fields that don't allow parameters. The upgrade will
> >     cause these fields to become synatically invalid.

> such as in accept headers?

Strawman again. There's nothing syntactically invalid about putting funny
wildcards in an accept header.

				Ned