Subject: Re: [xml-dev] Registration status
From: MURATA Makoto <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 21 Nov 2001 09:38:05 +0900 (JST)
List-Id: <ietf-xml-mime.imc.org>

From: Ian Graham <[email-masked]>
Subject: Re: [xml-dev] Registration status
Date: Sun, 18 Nov 2001 18:26:30 -0500 (EST)

> I think (ii) is the $1000 question.  A $500 question might be: "Did the
> authors of RFC 3023 consider the RFC 2912 mechanism for providing internal
> data about XML typed data?" (RFC 2912 isn't mentioned in 3023).

Yes, we were aware of RFC 2912.  We thus did not try to solve 
problems addressed by it.  I am happy to mention it in the next 
RFC for XML media types.

Cheers,

Makoto

Date: Sun, 18 Nov 2001 16:46:36 -0800 (PST)
From: [email-masked]
Subject: Re: [xml-dev] Registration status
To: Ian Graham <[email-masked]>
Cc: [email-masked], MURATA Makoto <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > i is a solved problem. ii remains to be seen. Thus far I've seen little use
> > made of this facility.

> I think (ii) is the $1000 question.  A $500 question might be: "Did the
> authors of RFC 3023 consider the RFC 2912 mechanism for providing internal
> data about XML typed data?" (RFC 2912 isn't mentioned in 3023).

While I suppose that feature lists could be used as a dispatch mechanism,
it isn't intended to be one, and in no way obviates the need for propoer
MIME types so dispatching can be done effectively.

> I can imagine many possible reasons (e.g., easy adaptation for current
> MIME dispatchers), but would like to know which one the authors found most
> compelling.

You'd have to ask them. At the time I was certainly aware of the mechanism, but
I didn't suggest it for the simple reason that I believe it to be completely
inappropriate in the context of what RFC 3023 seeks to do. That doesn't mean it
couldn't be a useful adjunct to RFC 3023, of course.

				Ned

Date: Sun, 18 Nov 2001 19:35:35 -0500 (EST)
From: Ian Graham <[email-masked]>
Reply-To: Ian Graham <[email-masked]>
To: Ian Graham <[email-masked]>
cc: [email-masked], MURATA Makoto <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [xml-dev] Registration status (corr.)
Sender: [email-masked]

On Sun, 18 Nov 2001, Ian Graham wrote:
...

> I think (ii) is the $1000 question.  A $500 question might be: "Did the
> authors of RFC 3023 consider the RFC 2912 mechanism for providing internal
> data about XML typed data?" (RFC 2912 isn't mentioned in 3023).
> 
> I can imagine many possible reasons (e.g., easy adaptation for current
> MIME dispatchers), but would like to know which one the authors found most
> compelling. 
> 

By which I meant to say "I can imagine many possible reasons for the model
presented in RFC 3023 (...."

Ian

Date: Sun, 18 Nov 2001 18:26:30 -0500 (EST)
From: Ian Graham <[email-masked]>
Reply-To: Ian Graham <[email-masked]>
To: [email-masked]
cc: MURATA Makoto <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [xml-dev] Registration status
Sender: [email-masked]

On Sun, 18 Nov 2001 [email-masked] wrote:

> 
> > My thinking is that, if an application is XML aware, it can take take
> > advantage of namespace identifiers to obtain more detailed 'subtype' data
> > than a content-type header can provide. The rationale for expanding this
> > outside of the content-type header is that the header is too limited to
> > express much detail about the payload content -- and, as you quite rightly
> > note, the parameter extension mechanism is largely ignored.
> 
> Defining additional header fields for this purpose is NOT the answer.
> There's already a very complete, extensible system for indicating media
> features in MIME. See RFC 2912 for details.

Thank you for this -- the mechanism described in 2912 (with syntax
detailed in RFC 2566) seems to allow for all that I (and I believe others)
have suggested, and much more.

> Defining the necessary tags for namespace identifiers and so on would seem
> to me to be reasonably straightforward.

Yes. 
 
> > The background questions, however, are these -- i) how can you reveal more
> > about the type of a MIME part, and ii) how useful would that information
> > really be.
> 
> i is a solved problem. ii remains to be seen. Thus far I've seen little use
> made of this facility.

I think (ii) is the $1000 question.  A $500 question might be: "Did the
authors of RFC 3023 consider the RFC 2912 mechanism for providing internal
data about XML typed data?" (RFC 2912 isn't mentioned in 3023).

I can imagine many possible reasons (e.g., easy adaptation for current
MIME dispatchers), but would like to know which one the authors found most
compelling. 

I'd also am curious to know if others see the contet-features: header as
an appropriate mechanisms for providing additional 'internal' data about
XML message parts.

Best wishes --

Ian

Date: Sun, 18 Nov 2001 07:24:45 -0800 (PST)
From: [email-masked]
Subject: Re: [xml-dev] Registration status
To: Ian Graham <[email-masked]>
Cc: MURATA Makoto <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> My thinking is that, if an application is XML aware, it can take take
> advantage of namespace identifiers to obtain more detailed 'subtype' data
> than a content-type header can provide. The rationale for expanding this
> outside of the content-type header is that the header is too limited to
> express much detail about the payload content -- and, as you quite rightly
> note, the parameter extension mechanism is largely ignored.

Defining additional header fields for this purpose is NOT the answer.
There's already a very complete, extensible system for indicating media
features in MIME. See RFC 2912 for details.

Defining the necessary tags for namespace identifiers and so on would seem
to me to be reasonably straightforward.

> The background questions, however, are these -- i) how can you reveal more
> about the type of a MIME part, and ii) how useful would that information
> really be.

i is a solved problem. ii remains to be seen. Thus far I've seen little use
made of this facility.

				Ned

Date: Fri, 16 Nov 2001 19:00:09 -0500 (EST)
From: Ian Graham <[email-masked]>
Reply-To: Ian Graham <[email-masked]>
To: MURATA Makoto <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [xml-dev] Registration status
Sender: [email-masked]

On Sat, 17 Nov 2001, MURATA Makoto wrote:

> From: Ian Graham <[email-masked]>
> Subject: Re: [xml-dev] Registration status
> Date: Thu, 15 Nov 2001 18:49:00 -0500 (EST)
> 
> > Any thoughts?
> 
> It is not clear to me how your proposal solves problems 
> described in Appendix A (especially, A.5) of RFC 3023. 
> 
> > A.5 Why not use a MIME parameter to specify that a media type uses XML
> >     syntax?
> > 
> >    For example, one could use "Content-Type: application/iotp;
> >    alternate-type=text/xml" or "Content-Type: application/iotp;
> >    syntax=xml".
> > 
> >    Section 5 of [RFC2045] says that "Parameters are modifiers of the
> >    media subtype, and as such do not fundamentally affect the nature of
> >    the content".  However, all XML-based media types are by their nature
> >    always XML.  Parameters, as they have been defined in the MIME
> >    architecture, are never invariant across all instantiations of a
> >    media type.
> > 
> >    More practically, very few if any MIME dispatchers and other MIME
> >    agents support dispatching off of a parameter.  While MIME agents on
> >    the receiving side will need to be updated in either case to support
> >    (or fall back to) generic XML processing, it has been suggested that
> >    it is easier to implement this functionality when acting off of the
> >    media type rather than a parameter.  More important, sending agents
> >    require no update to properly tag an image as "image/svg+xml", but
> >    few if any sending agents currently support always tagging certain
> >    content types with a parameter.

My thinking is that, if an application is XML aware, it can take take
advantage of namespace identifiers to obtain more detailed 'subtype' data
than a content-type header can provide. The rationale for expanding this
outside of the content-type header is that the header is too limited to
express much detail about the payload content -- and, as you quite rightly
note, the parameter extension mechanism is largely ignored.

Another issue would be multiply-typed data -- for example, an SVG document
containing MathML and XHTML. If an app is keying on the SVG content type,
then it may simply refuse to let me do anything with it, even if the
app can  ignore the SVG but still display the rest.

However, I should note that a namespace identification mechanism can't
handle backward-compatibility, nor can it handle things like */dtd+xml, so
I would see a role for both.

The background questions, however, are these -- i) how can you reveal more
about the type of a MIME part, and ii) how useful would that information
really be.

I think some on these lists are struggling with these questions.

Best wishes --

Ian

Date: Fri, 16 Nov 2001 09:38:44 GMT
From: David Carlisle <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [xml-dev] Registration status
Sender: [email-masked]

> Any thoughts?

sounds reasonable to me, although I vaguely remember some previous
discussion as to why having separate xxx+xml types was thought
preferable to having extra information layered over the xml type.

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

Date: Thu, 15 Nov 2001 18:49:00 -0500 (EST)
From: Ian Graham <[email-masked]>
Reply-To: Ian Graham <[email-masked]>
To: David Carlisle <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [xml-dev] Registration status
Sender: [email-masked]

On Mon, 29 Oct 2001, David Carlisle wrote:

Sorry for delay (been off line ...)
  
> 
> having to upgrade that installed base is exactly the problem with    
> the xxx+xml proposals. If XML is served as text or application/xml   
....
> 
> But if your mail agent comes across an xxx+xml document and it doesn't 
> know this type, basically it's stumped. It won't even (currently) by   
> default do the "obvious" thing of dropping the xxx+ and trying the more
> general xml mime type.
> 
> you say
> 
> > This of course, is all IMHO, as RFC 3023 explicitly supports you
> > serving all XML as application/xml if you really want to.  But as A.15
> > mentions, there are no apparent downsides from using custom types and
> > several advantages.
> 
....
>
> Incidentally it seems to be widely held belief that text/xml was a
> mistake and that xml ought almost always be in application/xml.  I don't
> really hold that view. For decades TeX users have sent tex markup as
> plain text emails and been more or less happy. I don't see
> (document-oriented) XML as significantly different. If someone sends me
> some email with some mathematics in, and I'm sat at a machine without a
> mathml renderer, I'd much rather just see the mathml markup inline  
> (which can be read, in small doses, honestly:-) than just be offered a
> file/save option on the grounds that the lovingly constructed
> mathematics is just unreadable application specific data.

I've been thinking about this one a bit more, and perhaps a useful
alternative would be to expand upon the XML 'type' information with extra
XML-specific headers ... something like:

Content-type: text/mathml
xml-primary-namespace:  http://www.whatever.org/namespace
xml-secondary-namespace: http://some.other.org/namespace
xml-secondary-namespace: http://and.another.org/namespace

Older MIME-aware applications would just use content-type, and ignore
the rest, while newer 'XML-aware' applications could use the namepace
headers to more finely 'type' the message content, and process it
appropriately.  

Any thoughts?

Ian