headers
Dan Kohn | 10 Mar 2000 23:08

RE: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)

I am cross-posting to ietf-822 <at> imc.org because Keith correctly points out
that <http://www.normos.org/ietf/draft/draft-murata-xml-02.txt> raises
fundamental architectural questions regarding the right way to integrate XML
and MIME.  Those issues have been discussed on ietf-xml-mime <at> imc.org and I
believe a rough consensus was achieved, but the purpose of this thread is to
try to confirm that. 

>why?  is there really much value in a default treatment of text/* xml 
>documents as plain text?  (the default doesn't seem to work well in
>practice for text/html) or is xml really likely to be used for
>image/*, audio/*, video/*, or model/* content?

>how do you figure that?  such categorization is the primary purpose of 
>top-level types.  and while I grant that XML could be used to represent
>images, audio, or video...it does not seem well-suited as a presentation
>layer for these.

Keith, I think this may be the crux of the disagreement.  For the "-xml"
suffix to make sense, I think it must be likely that XML structure data will
show up in multiple MIME top-level types AND that that data could be
generically processed in a useful way.  Those two constraints would imply
that XML is acting fundamentally as the presentation layer in the network
stack (apologies for obligatory OSI network stack reference), and that that
presentation information should be available to dispatchers that can make
use if it.

The fact that almost all subtypes based on XML can be generically processed
is addressed in the I-D and excerpted in my message, which I attach below.

As to whether subtypes based on XML belong in different top-level type, I
(Continue reading)

Permalink | Reply | 20 comments |
headers
Keith Moore | 11 Mar 2000 00:26
Picon

Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)

[ for ietf-822 readers: there has been a request on the ietf-types list
[ to define a new content-type called application/iotp.  IOTP happens
[ to be layered on top of XML.  some XML proponents have suggested that
[ it should instead be called application/iotp-xml and that all XML-based
[ content for which default handling would be useful should be named
[ with content-types ending in -xml.    I see this as a MIME-architecture
[ issue which needs to be carefully condsidered before such a convention
[ would be adopted.  

Ned writes:
> I expect to see heavy use of XML under model and image at least. I suspect
> there will be some use even under audio, video, and message.
> 
> This is why I'm strongly opposed to an top-level content-type. Like it or
> not, we chose the outermost facet of our typing space in such a way that
> XML has mutiple overlaps. It isn't even close to the orthogonality that's
> needed. And it is way too late to change our typing space choice.
> 
> This leaves us with suffixes as tne only option IMO. And while I'm not
> enthusiastic about the suffix, I don't agree that it does the harm that
> you seem to think it does.

the problem with adding this frob to the content-type is that it 
(a) encourages other folks to add other frobs, and 
(b) removes the "right side of a content-type" as a place where
anything else which is orthogonal to presentation encoding can be added.
and thus it limits the future extensibility of the content-type scheme.

maybe we need a frob to indicate that the content is
gzip-compressed?  surely that would be generally useful?
(Continue reading)

Permalink | Reply | 0 comments |
headers
ned.freed | 11 Mar 2000 01:43

Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)

> Ned writes:

> > I expect to see heavy use of XML under model and image at least. I suspect
> > there will be some use even under audio, video, and message.

> > This is why I'm strongly opposed to an top-level content-type. Like it or
> > not, we chose the outermost facet of our typing space in such a way that
> > XML has mutiple overlaps. It isn't even close to the orthogonality that's
> > needed. And it is way too late to change our typing space choice.

> > This leaves us with suffixes as tne only option IMO. And while I'm not
> > enthusiastic about the suffix, I don't agree that it does the harm that
> > you seem to think it does.

> the problem with adding this frob to the content-type is that it
> (a) encourages other folks to add other frobs, and
> (b) removes the "right side of a content-type" as a place where
> anything else which is orthogonal to presentation encoding can be added.
> and thus it limits the future extensibility of the content-type scheme.

But on the other hand, I don't see much value in labelling something with a
name that has a -xml suffix when te content isn't XML. Seems more than a bit
misleading, doesn't it?

> maybe we need a frob to indicate that the content is
> gzip-compressed?

No, because that's an encoding issue. If we want gzip to be labelled we
need to do a CTE for it. This is a red herring in this context.
(Continue reading)

Permalink | Reply | 62 comments |
headers
Keith Moore | 11 Mar 2000 01:57
Picon

Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)

> Again, I'm not especially supportive of the frob as I fail to see very much
> utility in it. But I also don't oppose it. I see it as "mostly harmless".

here's the question: say someone else wants to define another frob,
and it's orthogonal to xml.  does a type that uses both the new
frob and the xml frob then become application/foo-xml-newfrob 
or application/foo-newfrob-xml?  
or do MIME readers have to recognize both forms?
what happens when there are three frobs?
can they appear in any order?

if we're going to add frobs to content-types, then it seems like we
should do this in a way that allows for extensibility.

Keith
Permalink | Reply | 34 comments |
headers
Steve Waterbury | 11 Mar 2000 07:34
Picon

Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)

Keith Moore wrote:

> here's the question: say someone else wants to define another frob,
> and it's orthogonal to xml.  does a type that uses both the new
> frob and the xml frob then become application/foo-xml-newfrob
> or application/foo-newfrob-xml?
> or do MIME readers have to recognize both forms?

I vote for the latter.

> what happens when there are three frobs?
> can they appear in any order?

I think so ... the implementation would be somewhat similar to 
having a command recognize it's switches when they can occur in 
any order ... not so difficult, really.  

Cheers,
-- Steve.

                                           oo _\o
                                            \/\ \
                                              /
____________________________________________ oo _________________
"Sometimes you're the windshield; sometimes you're the bug."
- Knopfler

Stephen C. Waterbury                       Component Technologies
Code 562, NASA/GSFC                  and Radiation Effects Branch
Greenbelt, MD 20771           Engineering Web/Database Specialist
(Continue reading)

Permalink | Reply | 0 comments |
headers
ned.freed | 11 Mar 2000 20:40

Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)

> > Again, I'm not especially supportive of the frob as I fail to see very much
> > utility in it. But I also don't oppose it. I see it as "mostly harmless".

> here's the question: say someone else wants to define another frob,
> and it's orthogonal to xml.  does a type that uses both the new
> frob and the xml frob then become application/foo-xml-newfrob
> or application/foo-newfrob-xml?

And the answer is that we need to define a rule, probably as part of the
current proposal. It can be any of:

(1) Any additional things of this sort are always added after the -xml, and
    there's a clear ordering to them.

(2) Any additional things of this sort are always added before the -xml, and
    there's a clear ordering to them.

(3) Any additional things of this sort can be added before or after the -xml,
    but for any given type there is one and only one valid ordering.

I don't much care which of these we pick. In fact we actually don't even need
to have a rule now, but if we ever added another of these in the future we'd be
forced to use rule (2) at that point, since anything else would not be
backwards compatible.

> or do MIME readers have to recognize both forms?

Absolutely not. This would be a fundamental change to the namespace where names
would no longer be unique strings, and there's no need for it in any case.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pete Resnick | 11 Mar 2000 21:01

Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)

On 3/10/00 at 7:57 PM -0500, Keith Moore wrote:

>  > Again, I'm not especially supportive of the frob as I fail to see very much
>>  utility in it. But I also don't oppose it. I see it as "mostly harmless".
>
>here's the question: say someone else wants to define another frob,
>and it's orthogonal to xml.  does a type that uses both the new
>frob and the xml frob then become application/foo-xml-newfrob
>or application/foo-newfrob-xml?

Oy. The mind reels at what the MIME parsing code for this looks like.

I've really got to agree with Keith here; this is a mess and I oppose 
the direction it is taking. If XML-ishness needs to be called out as 
a property of a body part, it should be separated out as a parameter 
of some sort, or made a new field, not embedded as part of the name 
of a content-type. I know where in our code I can dispatch off of a 
parameter or a new field; that's easy. Dispatching off part of a name 
would be grotesque.

There are mechanisms in MIME to call out properties like this. Why 
are we trying to embed this particular one in the name instead of 
using the mechanisms that MIME provides?

pr
--

-- 
Pete Resnick <mailto:presnick <at> qualcomm.com>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Kohn | 11 Mar 2000 21:34

RE: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)

I appreciate Pete's concern here, and agree that in an ideal world, this
could be handled under Content-Disposition or some new sort of
Content-Structure header.   But my (perhaps mistaken) belief is that most
dispatching tools out there work off of MIME type, and do not necessarily
have access to arbitrary Content- headers.

To take just one example of the utility of putting the information in the
content type, think of web crawlers associated with search engines.  Most
web crawlers look only for "text/*" documents for archiving.  With the
"-xml" suffix rule, all existing web crawlers can be easily modified to
search for "*/*-xml" as well, opening up to search a huge quantity of data
that would otherwise be unavailable.  (Obvious caveats apply, that if you
don't want your data searchable, use robot tags.
<http://www.fast.no/fast.php3?d=support_faqs&c=crawler&h=3>)  These crawlers
would require significant changes to parse the rest of the HTTP headers as
well, and more important, most web authors have no way of adding arbitrary
MIME headers to their sites.

The point is that "-xml" has demonstratable benefit to a significant subset
of the community, while Pete and Keith have complained about the lack of
elegance of the solution.

Ned Freed has shown that a simple rule of "-xml" comes last will allow
extensibility.  However, we haven't needed any extensibility of the last 10
years and the popularity and extensibility of XML itself will hopefully mean
that we won't need to have this debate again for a long time.

In lieu of a proposal for a more elegant solution that also provides
complete backward (and easy upward) compatibility, I think we should move
forward with Murata-san's draft.
(Continue reading)

Permalink | Reply | 2 comments |
headers
ned.freed | 11 Mar 2000 22:00

Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)

> On 3/10/00 at 7:57 PM -0500, Keith Moore wrote:

> >  > Again, I'm not especially supportive of the frob as I fail to see very much
> >>  utility in it. But I also don't oppose it. I see it as "mostly harmless".
> >
> >here's the question: say someone else wants to define another frob,
> >and it's orthogonal to xml.  does a type that uses both the new
> >frob and the xml frob then become application/foo-xml-newfrob
> >or application/foo-newfrob-xml?

> Oy. The mind reels at what the MIME parsing code for this looks like.

Really. Funny, I see it as two lines of code, tops. All you have to do
is search for whatever tag you're interested in followed by a dash or
EOS. I have a route to do this sort of thing readily available. I suspect
most others do as well.

> I've really got to agree with Keith here; this is a mess and I oppose
> the direction it is taking. If XML-ishness needs to be called out as
> a property of a body part, it should be separated out as a parameter
> of some sort, or made a new field, not embedded as part of the name
> of a content-type. I know where in our code I can dispatch off of a
> parameter or a new field; that's easy. Dispatching off part of a name
> would be grotesque.

All of these approaches were explored in depth already on the XML-MIME list.
All of them have major disadvantages over the tagging scheme presently
proposed. I ended up in strong opposition to all of them, whereas I could find
no good reason to oppose this approach.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Harald Tveit Alvestrand | 11 Mar 2000 22:53
Picon

Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)

At 11:40 11.03.00 -0800, ned.freed <at> innosoft.com wrote:

>And the answer is that we need to define a rule, probably as part of the
>current proposal. It can be any of:
>
>(1) Any additional things of this sort are always added after the -xml, and
>     there's a clear ordering to them.
>
>(2) Any additional things of this sort are always added before the -xml, and
>     there's a clear ordering to them.
>
>(3) Any additional things of this sort can be added before or after the -xml,
>     but for any given type there is one and only one valid ordering.
>
>I don't much care which of these we pick. In fact we actually don't even need
>to have a rule now, but if we ever added another of these in the future 
>we'd be forced to use rule (2) at that point, since anything else would not be
>backwards compatible.

Seems to me that we could formulate this thing in the negative, rather than 
positive; forbid things that could cause confusion, rather than say that 
things should be a certain way:

"It is NOT allowed to register content-types that end in -XML when that
content-type is not parseable according to the XML standard, version
<insert appropriate number>".

This is enough to ascertain that if you hand *-XML to an XML parser, that 
parser will either grok it or be right in signalling an error, without 
saying that (for instance) application/iotp has to be application/iotp-XML,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane