Subject: Re: Finishing the XML-tagging discussion
From: Chris Newman <[email-masked]>
To: [email-masked]
Date: Tue, 25 Apr 2000 16:33:37 -0700
List-Id: <ietf-822.imc.org>

--On Friday, April 21, 2000 17:53 -0400 Keith Moore <[email-masked]> 
wrote:
> caveats: (1) it should be up to the folks defining the type to
> decide whether to use the -xml frob or not.

concur.

> (2) the interaction
> between the treatment of this frob and the rules about default
> handling of mime objects for user agents presenting those objects
> need to be clarified.

The MIME default handling should happen if a handler is set.  For example, 
I'd consider it much more useful to hand a "video/vnd.foobar.vector-xml" to 
the "video/*" handler rather than an XML editor.  The only debatable case 
is "text/*", but that's only because we broke the usefulness of default 
handing for "text/*" when we registered text/html and similar things which 
are rarely useful as plain text.

> (3) we need to understand how multiple frobs
> in the same content-type name work in case we ever need them. *

I'd look for "frob" handlers from right to left.

> (4) since "-" is already used in some content-types it might be
> worth considering a different separator.

Can't be a tspecial:
     tspecials :=  "(" / ")" / "<" / ">" / "@" /
                   "," / ";" / ":" / "\" / <">
                   "/" / "[" / "]" / "?" / "="
I don't think "." would work since it's already used as an additional 
hierarchy delimiter.  I wouldn't choose "*" due to the common wildcard 
meaning, or "-"/"_" since they're common word separators and easily 
confused.  And I'd avoid %, ', `, # and & since they are frequently used 
for quoting or comments.

That leaves: ~!$^+{}|

I note that "-" is used heavily in the current registry.  "$" and "_" are 
used once each.  The others are unused.

		- Chris

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: [email-masked]
Subject: Re: Finishing the XML-tagging discussion 
Date: Fri, 21 Apr 2000 17:53:30 -0400
Sender: [email-masked]

> Solution                Pros                    Cons
> 
> (a) application/        No change to            Not neat to require
> foobar-xml              MIME specs.             mailer to parse the
>                                                 subtype string.
> 

other con: potentially complicates content-negotiation schemes that 
are based on the content-type name.  and it's not just mailers that
are affected, since other things use the same content-type namespace.

I think most folks have settled on (a).  I still prefer (b) but
my main goal in raising a stink was to get MIME people to think 
about the implications of the decision before accepting it.
so I'll stop loudly objecting to (a).

I view the tradeoff between (a) and (b) as one of short-term
acceptance in the case of (a) vs. better long-term sanity in
the case of (b).  But MIME may be obsolete for other reasons
before we really have much trouble resulting from these frobs.

caveats: (1) it should be up to the folks defining the type to
decide whether to use the -xml frob or not. (2) the interaction
between the treatment of this frob and the rules about default 
handling of mime objects for user agents presenting those objects 
need to be clarified. (3) we need to understand how multiple frobs
in the same content-type name work in case we ever need them. *
(4) since "-" is already used in some content-types it might be
worth considering a different separator.

Keith

* I suspect we will need them eventually, though it might be a few
more years. I don't think that XML is the last word in presentation 
syntaxes, and some day there might even be generalized semantic 
conventions for tagged objects.

Date: 21 Apr 2000 20:24:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Finishing the XML-tagging discussion
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked] (Jacob Palme)  wrote on 21.04.00 in <v04210104b525c2f22a5b@[130.237.150.138]>:

> Possible solutions:
>
> (a) Use content-type such as application/foobar-xml, where
>     "-xml" tells the mailer, that if no special "foobar-xml"
>     handler is available, then a general-purpose application/xml
>     handler should be used.
>
> (b) Use content-type such as application/foobar, and add a
>     parameter to this content-type such as
>     Alternative-Content-Type: application/xml.
>
> (c) A variant of (b), where the added header is named
>     Super-Content-Type: application/xml.
>
> Pros and cons of the different solutions:
>
> Solution		Pros			Cons
>
> (a) application/        No change to		Not neat to require
> foobar-xml		MIME specs.		mailer to parse the
> 						subtype string.
                        Will be handled right
                        even by software
                        ignorant of the
                        convention
>
> (b) Alternative-	Easy to implement,	Some mailers which
> Content-Type parameter	neat.			do not know of this
> 						parameter may be
> 						confused.
                                                Also, worthless until
                                                supported by both sides
>
> (c) Super-		Gives MIME new		Should be carefully
> Content-Type parameter  powerful capability	thought-through
> 			with object-oriented	to fit other possible
> 			structure of content-	uses, what about
> 			types.			several levels of
> 						superclassing for example?
                                                Also, worthless until
                                                supported by both sides

> My conclusion is that (b) seems to be the best alternative, unless
> we want to really think through an object-oriented structuring of
> subtypes.

So far, I've found the arguments for a far more convincing than those for  
any alternative.

MfG Kai

From: [email-masked]
Date: Fri, 21 Apr 2000 11:03:52 -0800 (PST)
Subject: Re: Finishing the XML-tagging discussion
To: Jacob Palme <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> I have been reading the XML tagging discussion, here is a
> short summary of my understanding of the problem:

I don't agree at all with your assessment. In particular,

> (b) Alternative-	Easy to implement,	Some mailers which
> Content-Type parameter	neat.			do not know of this
> 						parameter may be
> 						confused.

is, in my opinion:

(b) Alternative-	Avoids possible 	Hard to implement in
Content-Type parameter  complications		many environments, extremely
			should many		hard to deploy. Introduces
			similar things		many obvious silly states.
			be needed in the
			future.

And we have agreement, even from those who appose (a), of the disadvantages of
(b).

And (c) should be:

(c) Super-		Gives MIME a badly	All the problems of (b),
Content-Type parameter  designed new 		must be very carefully
 			with some limited	designed, and even if
			object-oriented		carefully designed is
			capabilities.		guaranteed to be abused.

> My conclusion is that (b) seems to be the best alternative, unless
> we want to really think through an object-oriented structuring of
> subtypes.

My conclusion is that (a) wins overwhelmingly.

				Ned

Date: Fri, 21 Apr 2000 10:53:30 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: Finishing the XML-tagging discussion
Sender: [email-masked]

I have been reading the XML tagging discussion, here is a
short summary of my understanding of the problem:

The discussion relates to how a specialized application,
such as foobar, should label its MIME content-type, when
foobar uses XML as a basis for its encoding format.

Requirements:

(1) The normal MIME format should be used, with a content-type
    such as application/foobar.

(2) There is a need to indicate in the header, that foobar
    actually is based on XML.

(3) Body parts in the application/foobar format should be handled
    by a special foobar application handler. If, however, no
    foobar application handler is available, the applications
    should alternatively be handled by a generalized xml
    processor.

Possible solutions:

(a) Use content-type such as application/foobar-xml, where
    "-xml" tells the mailer, that if no special "foobar-xml"
    handler is available, then a general-purpose application/xml
    handler should be used.

(b) Use content-type such as application/foobar, and add a
    parameter to this content-type such as
    Alternative-Content-Type: application/xml.

(c) A variant of (b), where the added header is named
    Super-Content-Type: application/xml.

Pros and cons of the different solutions:

Solution		Pros			Cons

(a) application/        No change to		Not neat to require
foobar-xml		MIME specs.		mailer to parse the
						subtype string.

(b) Alternative-	Easy to implement,	Some mailers which
Content-Type parameter	neat.			do not know of this
						parameter may be
						confused.

(c) Super-		Gives MIME new		Should be carefully
Content-Type parameter  powerful capability	thought-through
			with object-oriented	to fit other possible
			structure of content-	uses, what about
			types.			several levels of
						superclassing for example?

My conclusion is that (b) seems to be the best alternative, unless
we want to really think through an object-oriented structuring of
subtypes.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: 07 Apr 2000 09:38:00 +0200
From: [email-masked] (Kai Henningsen)
To: [email-masked]
Subject: Re: Finishing the XML-tagging discussion
Organization: Organisation? Me?! Are you kidding?
Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
Sender: [email-masked]

[email-masked]  wrote on 21.03.00 in <[email-masked]>:

> On Mon, 20 Mar 2000 17:59:13 EST, "Simon St.Laurent" said:
> > It's a plausible risk only if HTTP 1.1 or other protocols are explicitly
> > reopened and modified.  Otherwise, it's pretty easy to point to the spec
> > and say "No.  That's forbidden."  It might be a good idea to present these
>
> If you haven't been in the industry long enough that it takes you more
> than 30 seconds to think of at least 5 vendors(*) of software who aren't
> dissuaded from doing something just because the standard says explicitly
> not to do that, you haven't been around enough to see *seriously* broken
> software.

Well, in case someone wants to expand the Accept: mechanism to allow this  
kind of matching, have a look at the wildmat patterns used, for example,  
in NNTP. It's already in a RFC, free source code is available, and it's  
compatible with the existing spec.

MfG Kai