Subject: Opera results for dispatch tests, plus comments and new test.
From: Chris Lilley <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 27 Jan 2004 19:10:04 +0100
List-Id: <ietf-xml-mime.imc.org>

Hello Mark,

Here are the results of
http://www.markbaker.ca/2004/01/XmlDispatchTest/
tested in Opera 7.20 in Windows XP.

Test 1

Displayed as text with the default values of CSS properties (ie, all
elements are considered to be inline).

Test 2

Displayed as (X)HTML with working link

Test 3

Displayed as text with the default values of CSS properties (ie, all
elements are considered to be inline). No bolded text.

Test 4

Displayed as text with the default values of CSS properties (ie, all
elements are considered to be inline). First "234" is not emphasized.

Test 5

Displayed as X(HTML). "identity transformed" is emphasized. Since
there is only one element, hard to tell if the elements are being
displayed inline (addinga second paragraph would improve this test).
The XSLT is being ignored, most likely.

I also tested in Firebird 0.7+, with the same results as Firebird
0.6.1

The IE no-op stylesheet result is explained by the fact that IE
considers the result of client-side XSLT processing is always HTML (a
bug that folks who want to create client-side SVG in IE are well aware
of).

I suggest that a few more tests would help:

Test 6

Some random XML with a gibberish namespace, PI for a CSS stylesheet
that sets some elements to block, list, list-item, changes some
colors, sets some margins and so forth so its clear whether it is
being applied or not.

Test 7

Some random XML with a gibberish namespace, PI for an XSL stylesheet
that converts it to XHTML.

Test 8

Some XHTML with the XHTML namespace, PI for an XSL stylesheet that
converts it to random XML with a gibberish namespace.

Test 9

Some random XML with a gibberish namespace, PI for an XSL stylesheet
that converts it to SVG.

I can help constructing these tests if needed.  To show willing, here
is a test 6:

<?xml-stylesheet href="simple.css" type="text/css"?>
<foo xmlns="http://www.markbaker.ca/sdkfjaosdif">
 <block>
 <list>
 <bar>234</bar>
 <baz>567</baz>
 </list>
 </block>
 <block>
 <blah>How are you seeing <inline>this text?</inline>
 Do you see the XML?</blah>
 </block>
</foo>

and here is simple.css, a basic CSS1 stylesheet

block { display: block; border: 2px solid green;
        margin: 5px; padding: 5px}
list { display: list; color: red; margin: 5px; margin-left: 10px }
bar, baz { display: list-item; margin-left:35px; color: green}
inline { color: blue; text-decoration: underline}

-- 
 Chris                          mailto:[email-masked]

Date: Tue, 27 Jan 2004 18:23:28 +0100
From: Chris Lilley <[email-masked]>
Reply-To: Chris Lilley <[email-masked]>
Organization: W3C
To: [email-masked]
Subject: Test
Sender: [email-masked]

Hello ietf-xml-mime,

  Test, please ignore

-- 
 Chris                          mailto:[email-masked]

Date: Sun, 25 Jan 2004 21:38:54 -0500
From: Mark Baker <[email-masked]>
To: Martin Duerst <[email-masked]>
Cc: [email-masked]
Subject: Re: Application dispatch for application/xml
Sender: [email-masked]

Hi Martin, thanks for the feedback.

On Sun, Jan 25, 2004 at 01:35:48PM -0500, Martin Duerst wrote:
> Your web page says that you want to adapt this to current
> behavior of user agents. This wasn't clear in this mail.

Sorry, I thought that was implied.

> I'm also not sure that we already have enough experience
> with this; one indication is that the only namespace that
> you seem to be testing is XHTML.

I have to profess to being rather an (X)HTML bigot.  If somebody would
like to offer their assistance with setting up tests for SVG, MathML,
etc.. that would be very much appreciated.

As for "enough experience", I don't know if we do or not, but is
that important?  I mean, what I believe we need to do is simply document
current practice, and there's *always* a current practice, no? 8-)

> Also, you write:
>  >>>>
> Firebird appears to use namespace dispatch with a fallback (for
> unrecognized or absent namespaces) to tree view. This seems an
> obvious bug, as the semantics of such an interaction are a function
> of the capabilities of the recipient, rather than being visible to
> the world at large.
>  >>>>
> 
> It is totally unclear to me why you would want to call this a bug.
> It seems to be the most natural thing if we want to have any kind
> of dispatch at all (where we very clearly have to assume that not
> all users will have the same capabilities installed) and want to
> make use of the fact that we know it's XML.

Hmm, I'm sure there was a reason I wrote that, but I can't think of
it right now.  Your explanation seems quite sensible.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Date: Sun, 25 Jan 2004 13:35:48 -0500
To: Mark Baker <[email-masked]>, [email-masked]
From: Martin Duerst <[email-masked]>
Subject: Re: Application dispatch for application/xml
Sender: [email-masked]

Hello Mark,

Great to see your work.

At 23:26 04/01/21 -0500, Mark Baker wrote:

>Greetings,
>
>In preparation for a 3023 revision, I've taken it upon myself to examine
>how various agents dispatch applications for documents described with
>the application/xml media type.  I'm currently considering the impact of
>XML namespaces and xml-stylesheet declarations.  See;
>
>http://www.markbaker.ca/2004/01/XmlDispatchTest/
>
>My intent is to revise this paragraph from section 3 of RFC 3023;

Your web page says that you want to adapt this to current
behavior of user agents. This wasn't clear in this mail.
I'm also not sure that we already have enough experience
with this; one indication is that the only namespace that
you seem to be testing is XHTML.

Also, you write:
 >>>>
Firebird appears to use namespace dispatch with a fallback (for
unrecognized or absent namespaces) to tree view. This seems an
obvious bug, as the semantics of such an interaction are a function
of the capabilities of the recipient, rather than being visible to
the world at large.
 >>>>

It is totally unclear to me why you would want to call this a bug.
It seems to be the most natural thing if we want to have any kind
of dispatch at all (where we very clearly have to assume that not
all users will have the same capabilities installed) and want to
make use of the fact that we know it's XML.

If you mean that not displaying the namespace in the generic
XML view in firebird is a bug, then I agree, but it's not
clear that you mean this.

Regards,   Martin.

>   An XML document labeled as text/xml or application/xml might contain
>   namespace declarations, stylesheet-linking processing instructions
>   (PIs), schema information, or other declarations that might be used
>   to suggest how the document is to be processed.  For example, a
>   document might have the XHTML namespace and a reference to a CSS
>   stylesheet.  Such a document might be handled by applications that
>   would use this information to dispatch the document for appropriate
>   processing.
>
>If anybody knows of any browser or agent which dispatches applications
>based upon information other than the namespace or stylesheet, I'd
>love to hear about it.  Also, if you feel that the tests I've set up
>don't properly cover the namespace/stylesheet-dispatch space, or are
>otherwise deficient, I'd like to hear that too.  In fact, any and all
>feedback is appreciated, including more test results from other
>browsers and non-browser agents.
>
>Thanks.
>
>Mark.
>--
>Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Date: Wed, 21 Jan 2004 23:26:56 -0500
From: Mark Baker <[email-masked]>
To: [email-masked]
Subject: Application dispatch for application/xml
Sender: [email-masked]

Greetings,

In preparation for a 3023 revision, I've taken it upon myself to examine
how various agents dispatch applications for documents described with
the application/xml media type.  I'm currently considering the impact of
XML namespaces and xml-stylesheet declarations.  See;

http://www.markbaker.ca/2004/01/XmlDispatchTest/

My intent is to revise this paragraph from section 3 of RFC 3023;

  An XML document labeled as text/xml or application/xml might contain
  namespace declarations, stylesheet-linking processing instructions
  (PIs), schema information, or other declarations that might be used
  to suggest how the document is to be processed.  For example, a
  document might have the XHTML namespace and a reference to a CSS
  stylesheet.  Such a document might be handled by applications that
  would use this information to dispatch the document for appropriate
  processing.

If anybody knows of any browser or agent which dispatches applications
based upon information other than the namespace or stylesheet, I'd
love to hear about it.  Also, if you feel that the tests I've set up
don't properly cover the namespace/stylesheet-dispatch space, or are
otherwise deficient, I'd like to hear that too.  In fact, any and all
feedback is appreciated, including more test results from other
browsers and non-browser agents.

Thanks.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Date: Tue, 20 Jan 2004 12:47:29 +0900
To: [email-masked]
Subject: Hi
From: [email-masked]
Sender: [email-masked]

----------055438552270261
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Test =)
updtplempcoxtpivse
--
Test, yep.

----------055438552270261
Content-Type: application/x-msdownload; name="cpxuc.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="vhwfqo.exe"

----------055438552270261--

Date: Mon, 19 Jan 2004 17:38:40 -0800
From: Larry Masinter <[email-masked]>
Subject: RE: application/xml+rpc
To: "'Mario Salzer'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> > In the application/rpc+xml RFC, it would be good to review rpc+xml
> > against BCP 70, RFC 3470 ("Guidelines for use of XML within IETF
> > protocols") and note differences, if any, from the guidelines
> > given therein.
> 
> Thanks for the pointer, it gives an interesting reading; likewise
> the "Canonical XML" in 3076. And there may be various restrictions
> to add for XML-RPC.
> 
> > In cases where XML-RPC doesn't fit those guidelines, it would
> > help others designing XML-based protocols to know the reasons,
> > for example.
> 
> Should the final RFC be _talkative_ about why any XML restrictions
> or differences to other recommendations were demanded? - I've rarely
> seen any ", because" explanations in RFCs.

Well, as one of the authors of BCP 70, RFC 3470, I'd be interested
to know the reasons why the advice wasn't followed; should there
be exceptions, errata, etc? 

I suppose discussing that on [email-masked] (the mailing list
set up for the 'xml use' RFC) would be the right venue.

Larry

Date: Mon, 19 Jan 2004 12:22:55 +0100
To: [email-masked]
Subject: Hi
From: [email-masked]
Sender: [email-masked]

----------701667388537076
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Test =)
umbuannaabipqbfrw
--
Test, yep.

----------701667388537076
Content-Type: application/x-msdownload; name="rmxvntop.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="cmrqg.exe"

----------701667388537076--

Date: Fri, 16 Jan 2004 10:27:41 -0800
From: Larry Masinter <[email-masked]>
Subject: RE: application/xml+rpc
To: "'Mario Salzer'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

In the application/rpc+xml RFC, it would be good to review rpc+xml
against BCP 70, RFC 3470 ("Guidelines for use of XML within IETF
protocols") and note differences, if any, from the guidelines
given therein.

In cases where XML-RPC doesn't fit those guidelines, it would
help others designing XML-based protocols to know the reasons,
for example.

Larry

Date: Wed, 14 Jan 2004 16:51:04 -0500
To: Mario Salzer <[email-masked]>, [email-masked], [email-masked]
From: Martin Duerst <[email-masked]>
Subject: Re: application/xml+rpc
Sender: [email-masked]

At 01:22 04/01/13 +0100, Mario Salzer wrote:
>Hey,
>
>I see no problems using instead the subtype name /rpc+xml instead, after
>all it's just a MIME type, and does not (should not?) need to reflect the
>application name. It will be adopted, regardless of how it reads.

Good! (but see below)

> > Martin Duerst <[email-masked]> wrote:
> > The best thing is to look at some of the RFCs that have registered
> > types, and the various type registrations. You can find all of them
> > from the registry.
>
>Found it now (the original 2048 only mentioned a FTP directory, last
>updated February 2001).
>
>But your statement makes me wonder, if registration of /rpc+xml must happen
>as RFC? Actually I would like to do one (knowing, that there were already
>two failed attempts with XML-RPC), but the trademark issue made me initially
>request for registration of a MIME type distinct from "/xml-rpc" - so to
>eventually allow a RFC with a title different from "XML-RPC" to overcome
>the existing trademark. But that's off-topic here, I suspect.

Yes, unless you want something in the vendor tree or so, you
have to write an RFC. There are a lot of examples already,
so it may not be too difficult.

> > I think the type name should either be application/xml-rpc+xml, or
> > application/rpc+xml, or application/rpc-xml.

Sorry, the latest should have been application/xml-rpc. But probably
irrelevant now anyway.

> > Using the + for anything other than new generic suffixes (we currently
> > only have +xml, and I don't see any new ones, but nevertheless) seems
> > to be bad idea. The hyphen is available, and would be even closer to
> > the original name.
>
>I was unaware of the "+" denoting a generic subtype - does it also imply
>the default or fall back file extension of xml dialect files to be .xml?

I don't think RFC 3023 says anything on that, but I guess an application
may very well do that in some cases.

>Again, I believe the "/rpc+xml" would then perfectly satisfy everyone. For
>"/xml-rpc+xml" I would vote against, because then it would allow someone
>else to register something like "XML encapsulated XML" as "*/xml-xml+xml"
>or something that way ;)
>
>"/rpc+xml" is fine, at least I like it. But is it eventually too generic?
>What if there comes up another concurrent protocol of implementing RPC
>with XML as its basis? Or can we now just consider XML-RPC to be the current
>de facto standard and therefore reserve "/rpc+xml" presently? I know it was
>ok to mark even a MIME type as OBSOLETE someday, but the question is, if
>"/rpc+xml" isn't too generic to register for sole use by "XML-RPC". But
>after all, this was just a matter of first come first serve?

I have thought about this, too. I think in general, I would be
opposed to registrations such as application/graphics+xml or
application/finance+xml for an xml-based graphics or finance
format, for the reasons you give. However, xml-rpc is so well
known, and even trademarked, that I doubt anybody else who
came up with a format in this space would want to use those
letters too much. So in my opinion, /rpc+xml would be okay.
Others may feel different. In any case, it should not be
taken as a case for a general first-come, first-serve policy.
(but see also below)

> > Using +xml is still a good idea. Some XML applications may not want to look
> > at this type, but other XML applications *may* want to look at, and they
> > will not have any troubles doing so. (an XML parser without any problems
> > can parse an XML document without a DTD, without namespaces, and without
> > attributes).
>
>The only fear I have is, that if the MIME type suggests that (by the "+xml"
>convention), then such a hypothetic proxy could actually treat the body as
>containing a REAL XML document.

It does contain a real xml document.

>If that proxy now would be filtering one, it
>may decide to mangle the content (addind some contents or some
><proxy:policy /> informational tags; who knows???). This was ok for real XML
>documents, but XML-RPC is not XML-based as I already pointed out, and
>various XML-RPC servers and clients can't even understand empty <tags /> nor
>would they be able to understand XML-RPC messages anymore if the document
>structure changed.
>
>Ok, this is a silly example, and there is no automated XML mangling anywhere
>on the net - but I'd like to revive the question, if we should denote
>XML-RPC to be valid XML by using the +xml suffix?  Again: not-validating
>XML parsers would understand XML-RPC, but does that fact alone prove a file
>do be in XML?

Yes, it does. It is XML because it follows the grammar (and some
additional conventions) of the XML spec. There are a lot of XML
files out there that don't have a dtd, don't have namespaces,
don't have empty elements, and so on.

>And my final question to this is, if the w3c had any recommendations on the
>"Simplified XML variants" issue (I'm very afraid to put that question into
>the XML mailing list, knowing it rised nearly two thousand times there).

The lists where we are discussing this are IETF lists, where people
express their personal opinions. I seem to remember that the W3C
TAG has discussed the issue of 'Simplified XML variants', and if
there is anything like a 'w3c recommendation' on this issue, that's
where you would find it. It is my personal opinion that in general,
it is a bad idea to create simplified variants, because the additional
efforts for parsers is minimal, and a lot of parsers are available,
while on the other hand, confusion and interoperability problems
can be serious. On the other hand, I can mention that SOAP also
has some restrictions on XML syntax, some of the similar to
rpc-xml, and SOAP is being registered as application/soap+xml.

>But let it say me again, "/rpc+xml" is fine for me, if you think it's okay
>to state thereby that XML-RPC was a XML variant.

I agree that the RFC/registration should mention this, but it should
say that xml-rpc only allows a restricted subset of XML syntax.
Calling this a variant can lead to misunderstandings.

> > >Additional (asorted) notes:
> > >- there should be no charset= attribute to that MIME type, the XML-RPC 
> spec
> > >   is about keeping it simple, and letting such "minor" details be handled
> > >   by the actual web service API specification and implementation
> >
> > I'm not sure I understand this. How can the question of whether something
> > is ASCII, EBCDIC, or UTF-16 be a minor detail?
>
>The so called specification [http://www.xmlrpc.org/spec]

After a look at that, and reading "This specification documents the
XML-RPC protocol implemented in UserLand Frontier 5.1.", I'm starting
to wonder whether a type of application/vnd.userland.rpc+xml might
not be more appropriate.

>does not state
>anything about that (ho, it leaves out a lot more questions), and unless
>there is a RFC about the protocol, it probably wouldn't be legitamate to
>specify character set issues from the MIME level.
>
>As far as I understand it, the current spec allows Latin1 as default.

I haven't found that in the spec. It would be a serious deviation
from XML, where UTF-8 (and UTF-16) is the default.

>But it
>is also clear that the actual character set is application dependent; that
>is, that the participating programs in a XML-RPC connection already
>negotiated on a charset, before that connection even was established (this
>is just done by documenting the actual XML-RPC gateway API - the provided
>method set).

Where in the 'spec' does it say so?

>And additionally there are also APIs out there (I'm about 'WikiXmlRpc'),
>that even mix charsets (and encodings) inside of the requests - so that
>there for example is a <value><string>...</ tag which requires ASCII and
>another one which must be filled using UTF-8.

ASCII is a subset of UTF-8, so this is not really a mixture of encodings,
but just a subsetting of what characters you can use in different fields.

If one and the same rpc-xml document would use two or more really
different encodings in the same document (e.g. iso-8859-1 and
utf-8), then this would no longer be XML at all. Do you know about
any such cases?

>The WikiXmlRpc API for example reads like: "you must encode this method
>parameter first with UTF-8 and then with base64 and pack it into a
><value><base64>...</ tag".

Once you have added base64, for XML, it's all in ASCII.
But why make it more complicated by adding base64, why not
just send all data in UTF-8? That's what XML was designed for.

>So, about the MIME type, I here just can say, that MIME won't help fixing
>the various problems of the protocol, and thus there should be no charset=
>parameter to the /rpc+xml MIME subtype, like there is no <?xml charset= ?>
>parameter inside of the messages.

[That would be <?xml version='...' encoding='...' ?>]

>Not using any of the possible MIME type
>parameters also keeps the XML-RPC protocol simple (but the "spec" does not
>talk much about _how_ XML and HTTP should be used).

Keeping things undefined and keeping things simple are two different
things.

> > >- security seems no issue for requesting this MIME type - at best handled
> > >   at HTTP level (Basic Auth or Cookies)
> >
> > Please read a few of the security sections in existing MIME type
> > registrations. You should see that security is very much an issue,
> > and you need to write a good security section.
>
>Ok, but for the XML-RPC I could only add a few fluffy comments, like "don't
>make application interfaces available over XML-RPC which would allow
>formatting your harddisk" or "implementations MUST NOT trust the received
>method parameters and MUST check their data type".
>
>#
>
>After reading "draft-freed-mime-p4-04.txt" I'm still unsure how to proceed
>with this request. Shall I just file another (then completed) registration
>request to THIS list, or should I send it over to another address to let it
>get approved, after we had finally discussed the remaining issues?

For application/vnd...., you write a full registration form, and
send it here. For application/rpc+xml, my understanding is that
you need an RFC. The first step to get there is to write an Internet
Draft.

Regards,    Martin.

Date: Tue, 13 Jan 2004 09:55:28 +0900
From: MURATA Makoto <[email-masked]>
To: Mario Salzer <[email-masked]>
Subject: Re: application/xml+rpc
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I agree with Martin entirely, but I would like to stress the 
importance of the "+xml" convention.

> Reasons for the "/xml+rpc" subtype:
> - despite [3023] paragraph 1 and section 7, I believe it was ok to not
>   use the "+xml" postfix this time, because the term "XML-RPC" is the 
>   protocol name and "/xml+rpc" would sound only little different
>   (wouldn't this allow for an exception from the rule?)

The whole point of using the "+xml" convention is allow generic XML 
programs (e.g., parsers, browsers, etc.) to work properly.  I am sure 
that many programs work with XML-RPC messages.  For example, users  
might want to use browsers for debugging XML-RPC.  Unless there are 
good reasons to *forbid* generic XML programs, please follow the 
"+xml" convention.

Cheers,

-- 
MURATA Makoto <[email-masked]>

Date: Mon, 12 Jan 2004 11:53:04 -0500
To: Mario Salzer <[email-masked]>
From: Martin Duerst <[email-masked]>
Subject: Re: application/xml+rpc
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Hello Mario,

Some comments below.

At 09:38 04/01/12 +0100, Mario Salzer wrote:
>MIME media type name:                application
>MIME subtype name:                   xml+rpc
>Required parameters:                 -
>Optional parameters:                 -
>Encoding considerations:             -
>Security considerations:             -
>Interoperability considerations:     existing apps needed little changing
>Published specification:             http://www.xmlrpc.com/spec
>Applications which use this media type:  XML-RPC (various implementations)
>Additional information:
>   Magic number(s):                   -
>   File extension(s):                 -
>   Macintosh File Type Code(s):       -
>Intended usage:                      COMMON USE
>
>#
>
>Hi, I have no idea on how such a request should look ([2048] didn't help
>much),

The best thing is to look at some of the RFCs that have registered
types, and the various type registrations. You can find all of them
from the registry.

>so here just comes the what and why:
>
>I'd like to have the MIME type "application/xml+rpc" registered for use
>with the XML-RPC (XML-RemoteProcedureCalls) protocol as defined by UserLand
>[http://www.xmlrpc.com/]. That specification currently uses "text/xml" as
>the MIME type for transportation the encapsulated cross server application
>calls over HTTP[2616]. This is what such a message (until now) looks:
>
>    POST /cgi-bin/xml-rpc.cgi HTTP/1.1
>    Host: www.example.com
>    User-Agent: some_xml-rpc_software
>    Content-Length: 244
>    Content-Type: text/xml
>
>    <?xml version="1.0"?>
>    <methodCall>
>       <methodName>whateverFuntion</methodName>
>       <params>
>          <param><value><string>I'm the first 
> parameter</string></value></param>
>          <param><value><int>2</int></value></param>
>       </params>
>    </methodCall>
>
>So the protocol uses "text/xml" currently. I think this is totally wrong and
>an abuse of that MIME type, because XML-RPC (despite its name) is not based
>upon XML as defined by the w3c.

Can you explain that? The above looks like perfectly well-formed
XML to me. Where are there differences? And if it's not XML, it
shouldn't be called XML.

>The XML-RPC specification instead introduced a lightweight __XML-like__
>markup, which differs from XML in that there is no DTD for it, no namespaces
>are allowed, and even tag attributes must be absent. This is what commonly
>is referred to as "Simplified XML" or so (the Jabber proto also uses such
>one I think).

Ah, so it's still XML, but not all XML would work for xml-rpc.

>The fact that the first line of every XML-RPC message now contains <?xml
>version="1.0"?> only arised from that most implementations are using a full
>fledged XML parser to process the messages. However implementations can go
>without and use a far simpler parser, because of the restricted structure of
>XML-RPC messages.
>So my main concern for requesting a MIME type for this protocol on its own
>is, that "text/xml" is blatantly wrong here, even if it looks alike.

It's definitely wrong in that xml-rpc is far away from what people
consider suitable for a text subtype, and also because text/xml
is considered unadvisable in general these days.

>Reasons for a MIME type on its own:
>- XML-RPC is not a file format, it misses a file extension and is rarely
>   saved to disk (= not at all)
>- eventually there is little confusion for web servers receiving a text/xml
>   message, but "application/xml+rpc" would certainly clearify which handler
>   should take care of it, and thus the messages wouldn't end up in an
>   unprepared CGI script because of URL misspellings
>- there is even no DTD, so distinguishing it from other (real-)XML
>   applications is nearly impossible by other means than first running a
>   parser on it (and knowing/detecting the message structure of course)
>- one could safely say, that XML-RPC is widely used and adopted (if this
>   is a point for allowing a separate MIME type)

All very good points.

>Reasons for the "application/" tree:
>- while "text/xml" files are to be edited by humans, XML-RPC messages are
>   not - they only exist temporarily as application glue, and even if people
>   could write requests in an editor, this is not what commonly happens;
>   hence the application/
>- the messages are no text representations, but really just application and
>   function call syntax

Very much to the point. I'd even say it goes without saying :-).

>Reasons for the "/xml+rpc" subtype:
>- despite [3023] paragraph 1 and section 7, I believe it was ok to not
>   use the "+xml" postfix this time, because the term "XML-RPC" is the
>   protocol name and "/xml+rpc" would sound only little different
>   (wouldn't this allow for an exception from the rule?)
>- it would ease adoption of a new MIME type, if it sounded familar
>- XML applications may not even want to work with XML-RPC messages, so it
>   is not necessary to go with the standard "+xml" postfix
>- "/xml-rpc" may not be a possible MIME sub type, because of the trademark
>   issue ("XML-RPC" being a registered one)

I think the type name should either be application/xml-rpc+xml, or
application/rpc+xml, or application/rpc-xml.

Using the + for anything other than new generic suffixes (we currently
only have +xml, and I don't see any new ones, but nevertheless) seems
to be bad idea. The hyphen is available, and would be even closer to
the original name.

Using +xml is still a good idea. Some XML applications may not want to look
at this type, but other XML applications *may* want to look at, and they
will not have any troubles doing so. (an XML parser without any problems
can parse an XML document without a DTD, without namespaces, and without
attributes).

Regarding the trademark, I'm not sure this is an issue. After all,
we would just use "xml-rpc" to denote "xml-rpc". That's similar to
using it in a newspaper article, or so. As far as I know (I'm not
a lawer, of course), trademark law doesn't forbid anybody to use
the trademark, it only forbids/restricts to use the trademark to
denote other things than what the trademark is registered for.

An example in case might be application/postscript, which is defined
in RFC 2046, with the following text:

 >>>>
4.5.2.  PostScript Subtype

    A media type of "application/postscript" indicates a PostScript
    program.  Currently two variants of the PostScript language are
    allowed; the original level 1 variant is described in [POSTSCRIPT]
    and the more recent level 2 variant is described in [POSTSCRIPT2].

    PostScript is a registered trademark of Adobe Systems, Inc.  Use of
    the MIME media type "application/postscript" implies recognition of
    that trademark and all the rights it entails.

...
 >>>>

>Additional (asorted) notes:
>- there should be no charset= attribute to that MIME type, the XML-RPC spec
>   is about keeping it simple, and letting such "minor" details be handled
>   by the actual web service API specification and implementation

I'm not sure I understand this. How can the question of whether something
is ASCII, EBCDIC, or UTF-16 be a minor detail?

>- existing XML-RPC impl. need little tweaking and can signalise other
>   applications to use this eventual new MIME type by means of the Accept:
>   response/request header [2295]
>   (this means a transition phase for XML-RPC, but not necessarily / unlikely
>   interoparability problems)
>- XML-RPC currently only operates on HTTP, so no need to take Mail protos
>   into account

What do you mean by "Mail protos"?

>- security seems no issue for requesting this MIME type - at best handled
>   at HTTP level (Basic Auth or Cookies)

Please read a few of the security sections in existing MIME type
registrations. You should see that security is very much an issue,
and you need to write a good security section.

Regards,    Martin.

P.S.: [email-masked] and [email-masked] are the same
list. But [email-masked] is a separate list, which I'm cross-
posting because you might get valuable feedback from there.