ietf-xml-mime
[Top] [All Lists]

Re: Finishing(!) the XML-tagging discussion

2000-03-21 09:41:23
(Apologies in advance for the syntax of my examples here. I'm not bothering
to check them carefully.)

my position is that requiring a separate label to facilitate
content negotiation makes it entirely too likely that the
separate label will be incorrect or omitted.  so any proposal
for an xml frob that says "don't use this frob for content-negotiation"
is a non-starter - it's headed 180 degrees in the wrong direction.

Keith, with all due respect, this strikes me as a fine academically
pure view, but unfortunately one that's entirely divorced from reality.

The reality is that feature expressions and their associated tags are
being used in at least four different ways:

(1) As a standalone negotiation mechanism.
(2) As an adjunct to an existing negotiation mechanism.
(3) As a standalone means of labelling objects.
(4) As an adjunct to an existing object labelling mechanism.

These multiple different uses make it inevitable that tags will be registered
that result in silly states. Consider, for example, (1) and (2). (1) as
manifested in Internet FAX makes it necessary to register things like media
types and charsets as feature tags. But (2) as manifested in HTTP leads to the
possibility of:

   accept-charset: UTF-8
   accept-features: (charset=ISO-2022-JP)

Or consider (3) and (4). (3) again requires registration of things like
media types. But (4) in the case of email makes it possible to say:

   content-features: (media-type="text/plain")
   content-type: application/octet-stream

Now, the only ways I can think of to address this problem are:

(a) Prohibit the registration of tags that duplicate other labels. Problem
    is, this breaks (1) and (3) completely, and also breaks (2) and (4)
    in cases where some labels from other contexts aren't available. So
    this dog doesn't hunt.
(b) Prohibit the use of tags in a given context that duplicate labels used
    in that context. Problem is that such a rule is quite difficult to
    write given that the existing label set is a moving target in many
    contexts, and effectively unenforceable in any case. So this dog doesn't
    hunt either.
(c) Prohibit the use of tags whose values conflict with the labels in a
    given context. But this amounts to sayin, "Don't produce stuff with silly
    states"; it doesn't provide the guarantee you're demanding.
(d) Have different sorts of feature expressions for the different cases.
    But this multiplies the number of mechanisms to a ridiculous degree.

Moreover, given the complexity of feature expressions it actually is possible
to have silly states within a single expression:

accept-features: (&((charset=UTF-8),(charset=ISO-2022-JP)))

accept-features: (&((language=ger),(language=fre)))

And ironically, determining that an arbitrary feature expression actually
describes a silly state turns out to be NP-hard! (It's obviously equivalent to
the classic satisfiability problem.)

The bottom line here is that silly states abound in the world of content
negotiation. That's the nature of the beast, and there's nothing you can do to
change it. You are tilting at windmills here.

This is why I've always considered the criteria for viable content negotiation
labelling to be totally separate from the straightforward labelling we've
been talking about here. Trying to combine the two inevitably creates
requirements that are, so to speak, unsatisfiale.

Now, let's return for a moment to the issue at hand (please note I didn't use
XML once in any of the above examples). I've said previously that your proposal
of a content-type parameter leads directly and inevitably to a new feature tag
being needed, so if new feature tags are unacceptable to you your own proposal
has to be unacceptable as well. It occurs to me that some of the readers of
this thread may not understand why this is so. The reason is simple: The
defined mechanism for putting content-type information in feature expressions
(draft-ietf-conneg-content-features-02.txt) provides a means of  checking media
types in feature expressions but no means of checking that a given parameter is
present on an arbitrary media type. And the current doctrine is that rather
than developing a mechanism for checking arbitray media type parameters those
parameters important enough to check will receive their own tag. See, for
example, draft-hoffman-char-lang-media-02.txt, where one such tag is
proposed.

Amusingly enough, I sent a note to the IESG arguing that the omission
of a facility to check MIME parameters in feature expressions was an
oversight that should be corrected. But I was alone in believing this, so
it didn't happen. (You were, as I recall, supportive of the document as-is
and silent on this particular point.)

                                Ned