[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
> (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?
> > > 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.
> > > Third, this introduces the possibility of silly states in a major way.
> > As far as I can tell, parameters already have tremendous potential for
> > silly states - nothing stops you from adding any parameter to any media
> > type (so you can for example have a charset parameter on an image).
> While this may be a silly state in some sense, it is an entirely harmless one.
> The silly states this superclass nonsense introduces are anything but.
> > But in practice, and despite widespread misuse of certain parameter
> > names with content-types that don't define those parameters, it doesn't
> > seem to cause big problems. Unrecognized parameters are generally
> > ignored.
> Exactly. We were careful to define parameters in this way so that bad
> behavior as a result of silly states was minimized. But this isn't possible
> with the sort of parameter you're proposing.
I don't buy it. all of the examples of silly states I can think of
are at worst equivalent to just mislabelling the content-type, which
already happens. if you mislabel an object's content-type you should
expect to lose, and I don't see how having the ability to mislabel
parameters changes this.
now I will admit that having the extra parameter creates *additional*
states - for instance, if you as a sender don't want to encourage
default processing of your xml document, you can omit the extra parameter.
but while I'm not sure how much value there is in this, those states
don't quite seem "silly" to me.
> > > Fourth, the infrastructure upgrades to handle this are far nastier
> > > than you seem to think, and have to happen at both the sending and receiving
> > > end.
> > I guess the question in my mind is whether those upgrades affect every
> > MIME handling agent or whether (for the time being) they only affect
> > things that care specifically about XML.
> In order for this to be useful they have to affect every agent.
again, how is this different than the -xml convention?
in either case, an agent that doesn't understand the convention
will ignore it and not be able to benefit from the extra information.
and an agent that does understand the convention will use it.
in either case, the convention is "useful" for those agents
that implement it and is benign for those that don't.
in neither case can a sender expect generic XML processing as a fallback
because (unlike text/plain processing) XML processing is not required
of MIME user agents.
> > The latter set seems a lot
> > smaller than the former set, and I'm less worried about the impact of
> > this on XML-aware agents (which after are in an emerging space anyway)
> > than I am worried about the impact of -xml frobs on things that need
> > to do content-negotiation (which includes every HTTP client and server).
> This is a complete red herring. Nobody is proposing that the suffix be
> used for negotiation purposes. Negotiation is a different problem than
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.
> > > Fifth, as I said before, this doesn't work with places where only media
> > > types and not parameters are carried. Such places do exist and fixing
> > > them all is going to be nearly impossible.
> > Since I see this parameter as advisory, to me it doesn't matter much.
> > Applications for which the advisory parameter is of sufficient utility
> > will get fixed to interpret or generate that parameter; those that don't
> > benefit sufficiently will not get fixed.
> Again, an advisory parameter of this sort accomplishes nothing.
"nothing" seems to me like a gross exaggeration.
> > 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.
> > > 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
> 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
> > 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.
if on the other hand, we take both cases and feed them to
"any existing handler" (say, a typical MIME mail reader)
then in the former case the $superclass is ignored and in the latter
case the charset is ignored. in either case the content is either
fed to a jpeg reader, or to a generic image/* reader, or it is
treated as application/octet-stream.
but since we're really trying to compare putting the xml frob into
a separate parameter vs. putting it into the content-type name,
perhaps that should be one axis of the case analysis. the other
obvious axis is existing MIME readers vs. MIME readers taught to
understand the new syntax.
> (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?
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?
(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
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?
> Now consider
> what happens when something that's incapable of generating the tag sends
> to the agent that requires it.
the agent either knows how to handle that specific content-type, or it
treats it per the fallback rule for the top-level content-type, or it
treates it as application/octet-stream.
but I fail to see why a well-behaved application would "require"
the extra parameter. if it knows what image/svg is, why would
it insist that the $superclass parameter be present?
> (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?
> I could go on to list many more, but hopefully this gives some flavor
> of how bad I think this idea is.