Subject: Hi
From: iana at iana.org ([email-masked])
Date: Sat Jan 24 13:57:21 2004

Test =)
juonmymriikwo
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtrqkbymi.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040124/024c2a47/vtrqkbymi.bin
>From [email-masked]  Mon Jan 12 09:38:03 2004
From: mario at erphesfurt.de (Mario Salzer)
Date: Tue Jan  3 16:22:39 2006
Subject: application/xml+rpc
Message-ID: <[email-masked]>

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), 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.
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).

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.

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)

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

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)

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
- 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
- security seems no issue for requesting this MIME type - at best handled
  at HTTP level (Basic Auth or Cookies)

Best regards,
mario

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
juonmymriikwo
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtrqkbymi.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040124/024c2a47/vtrqkbymi-0002.bin

From: iana at iana.org ([email-masked])
Date: Tue Jan 20 05:49:53 2004
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
sqouvnlbsyrbfypdevnlx
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fitggtjtudl.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040120/850a804f/fitggtjtudl.bin
>From [email-masked]  Tue Jan 20 07:54:19 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan 20 08:02:34 2004
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
iedlihrlriyvhf
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nharkyfitqt.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040120/02834ff8/nharkyfitqt-0001.bin
>From [email-masked]  Tue Jan 20 10:25:33 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan 20 10:17:01 2004
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
edtjvkdfavifdsiba
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bhtqoynsp.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040120/56b6266a/bhtqoynsp.bin
>From [email-masked]  Tue Jan 20 11:56:51 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan 20 11:56:50 2004
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
atrfaysspwiynsnsfxodid
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmwdgw.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040120/7d5f43bc/cmwdgw-0001.bin
>From [email-masked]  Thu Jan 22 20:49:56 2004
From: mark.nottingham at bea.com (Mark Nottingham)
Date: Thu Jan 22 20:50:01 2004
Subject: application/soap+xml
Message-ID: <[email-masked]>

A new draft of the application/soap+xml media type registration is 
available;
   http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-04.txt

This draft incorporates the actual registration data, making the 
document self-contained, and tweaks some minor details (such as the 
contact). The substance of the registration is unchanged.

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
sqouvnlbsyrbfypdevnlx
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fitggtjtudl.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040120/850a804f/fitggtjtudl-0002.bin
>From [email-masked]  Tue Jan 20 07:54:19 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
iedlihrlriyvhf
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nharkyfitqt.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040120/02834ff8/nharkyfitqt-0002.bin
>From [email-masked]  Tue Jan 20 10:25:33 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
edtjvkdfavifdsiba
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bhtqoynsp.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040120/56b6266a/bhtqoynsp-0002.bin
>From [email-masked]  Tue Jan 20 11:56:51 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
atrfaysspwiynsnsfxodid
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmwdgw.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040120/7d5f43bc/cmwdgw-0002.bin
>From [email-masked]  Thu Jan 22 20:49:56 2004
From: mark.nottingham at bea.com (Mark Nottingham)
Date: Tue Jan  3 16:22:40 2006
Subject: application/soap+xml
Message-ID: <[email-masked]>

A new draft of the application/soap+xml media type registration is 
available;
   http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-04.txt

This draft incorporates the actual registration data, making the 
document self-contained, and tweaks some minor details (such as the 
contact). The substance of the registration is unchanged.

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan 20 02:39:50 2004
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
Message-ID: <[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

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:40 2006
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
Message-ID: <[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

From: iana at iana.org ([email-masked])
Date: Mon Jan 19 09:45:56 2004
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
jydvsu
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: epfrfjjiu.exe
Type: application/x-msdownload
Size: 15873 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040119/10602dd2/epfrfjjiu-0001.bin
>From [email-masked]  Mon Jan 19 10:31:15 2004
From: iana at iana.org ([email-masked])
Date: Mon Jan 19 10:31:19 2004
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
sajbwjnc
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hgc.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040119/753d7edd/hgc.bin
>From [email-masked]  Tue Jan 20 01:51:03 2004
From: LMM at acm.org (Larry Masinter)
Date: Tue Jan 20 01:51:35 2004
Subject: New version of PDF registration draft
Message-ID: <[email-masked]>

I submitted what I hope is the final draft of the "PDF registration"
document, draft-zilles-pdf-02.txt.

After re-reading RFC 2026 more carefully, I removed the entire
section that was giving trouble (Section 6 on Intellectual
Property). 

The document is not intended for standards track. The
standard XML2RFC boilerplate includes RFC 2026 Section
10.4 (A)   "The IETF takes no position regarding ..."
and (B) "The IETF invites any interested party to bring ...",
even though RFC 2026 only requires those for standards track
documents. If needed (e.g., if the document were to be
moved to standards track), I believe I can get Adobe to make an
Intellectual Property statement that repeats the information
contained in the PDF Reference manual (as modified by
its errata) in a separate statement to be included in the
IETF list of IPR statements.

The only other content change was to take the wording
from RFC 2854 (text/html) about Javascript execution
environments.

Larry
-- 
http://larry.masinter.net

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
jydvsu
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: epfrfjjiu.exe
Type: application/x-msdownload
Size: 15873 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040119/10602dd2/epfrfjjiu-0002.bin
>From [email-masked]  Mon Jan 19 10:31:15 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
sajbwjnc
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hgc.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040119/753d7edd/hgc-0002.bin
>From [email-masked]  Tue Jan 20 01:51:03 2004
From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:40 2006
Subject: New version of PDF registration draft
Message-ID: <[email-masked]>

I submitted what I hope is the final draft of the "PDF registration"
document, draft-zilles-pdf-02.txt.

After re-reading RFC 2026 more carefully, I removed the entire
section that was giving trouble (Section 6 on Intellectual
Property). 

The document is not intended for standards track. The
standard XML2RFC boilerplate includes RFC 2026 Section
10.4 (A)   "The IETF takes no position regarding ..."
and (B) "The IETF invites any interested party to bring ...",
even though RFC 2026 only requires those for standards track
documents. If needed (e.g., if the document were to be
moved to standards track), I believe I can get Adobe to make an
Intellectual Property statement that repeats the information
contained in the PDF Reference manual (as modified by
its errata) in a separate statement to be included in the
IETF list of IPR statements.

The only other content change was to take the wording
from RFC 2854 (text/html) about Javascript execution
environments.

Larry
-- 
http://larry.masinter.net

From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
hqbadlemmnweirdwsm
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: macmpiyo.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040119/280505a7/macmpiyo-0002.bin
>From [email-masked]  Mon Jan 19 07:06:43 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
tflvhghxivyxsopklaq
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: funuld.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040119/152b36c0/funuld-0002.bin
>From [email-masked]  Mon Jan 19 08:10:41 2004
From: iana at iana.org ([email-masked])
Date: Tue Jan  3 16:22:40 2006
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
jnllvsdsgjqweoqio
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmupf.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20040119/c447fd27/cmupf-0002.bin
>From [email-masked]  Mon Jan 19 09:17:42 2004
From: technik at willms-edv.de (L.Willms)
Date: Tue Jan  3 16:22:40 2006
Subject: Hi -- what virus?
Message-ID: <[email-masked]>

On Mon, 19 Jan 2004 14:19:40 +0900, [email-masked] wrote:

> Received: from w6t7z7 ([221.163.136.159])
> 	by pechora.icann.org (8.11.6/8.11.6) with SMTP id i0J5Lu812344
> 	for <[email-masked]>; Sun, 18 Jan 2004 21:21:56 -0800
> Date: Mon, 19 Jan 2004 14:19:40 +0900
> To: [email-masked]
> From: [email-masked]
> Message-ID: <[email-masked]>

> MIME-Version: 1.0
> Content-Type: multipart/mixed;
>         boundary="--------257380553721802"
> Cc: 
> Subject: Hi
> X-BeenThere: [email-masked]
  ... 
> Sender: [email-masked]
> Errors-To: [email-masked]
> 
>  Test =)
> hqbadlemmnweirdwsm
> --
> Test, yep.

  Looks rather like a test how good are the spam and virus defenses on 
this list... 

Yours, 
L?ko Willms
-----------------------------------------------
Frankfurt/Main  

From: mario at erphesfurt.de (Mario Salzer)
Date: Sat Jan 17 22:51:13 2004
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[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.

mario
>From [email-masked]  Mon Jan 19 06:19:40 2004
From: iana at iana.org ([email-masked])
Date: Mon Jan 19 06:20:00 2004
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
hqbadlemmnweirdwsm
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: macmpiyo.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040119/280505a7/macmpiyo.bin
>From [email-masked]  Mon Jan 19 07:06:43 2004
From: iana at iana.org ([email-masked])
Date: Mon Jan 19 07:03:25 2004
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
tflvhghxivyxsopklaq
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: funuld.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040119/152b36c0/funuld-0001.bin
>From [email-masked]  Mon Jan 19 08:10:41 2004
From: iana at iana.org ([email-masked])
Date: Mon Jan 19 08:08:49 2004
Subject: Hi
Message-ID: <[email-masked]>

 Test =)
jnllvsdsgjqweoqio
--
Test, yep.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmupf.exe
Type: application/x-msdownload
Size: 15872 bytes
Desc: not available
Url : http://eikenes.alvestrand.no/pipermail/ietf-types/attachments/20040119/c447fd27/cmupf.bin
>From [email-masked]  Mon Jan 19 09:17:42 2004
From: technik at willms-edv.de (L.Willms)
Date: Mon Jan 19 09:17:55 2004
Subject: Hi -- what virus?
Message-ID: <[email-masked]>

On Mon, 19 Jan 2004 14:19:40 +0900, [email-masked] wrote:

> Received: from w6t7z7 ([221.163.136.159])
> 	by pechora.icann.org (8.11.6/8.11.6) with SMTP id i0J5Lu812344
> 	for <[email-masked]>; Sun, 18 Jan 2004 21:21:56 -0800
> Date: Mon, 19 Jan 2004 14:19:40 +0900
> To: [email-masked]
> From: [email-masked]
> Message-ID: <[email-masked]>

> MIME-Version: 1.0
> Content-Type: multipart/mixed;
>         boundary="--------257380553721802"
> Cc: 
> Subject: Hi
> X-BeenThere: [email-masked]
  ... 
> Sender: [email-masked]
> Errors-To: [email-masked]
> 
>  Test =)
> hqbadlemmnweirdwsm
> --
> Test, yep.

  Looks rather like a test how good are the spam and virus defenses on 
this list... 

Yours, 
L?ko Willms
-----------------------------------------------
Frankfurt/Main  

From: mario at erphesfurt.de (Mario Salzer)
Date: Tue Jan  3 16:22:40 2006
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[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.

mario

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:40 2006
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
Message-ID: <[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

From: mario at erphesfurt.de (Mario Salzer)
Date: Tue Jan  3 16:22:40 2006
Subject: application/xml+rpc
Message-ID: <[email-masked]>

> This is an important protocol, and you want the transport type to be
> registed in the IETF tree. So write an RFC.
> ...
> The deviations are OK if described in human-readable form in an RFC. Isn't
> it actually a subset of XML?

Yep, I've already begun that. And as that earlier published draft
("XMC") on it provides some well written paragraphs on this issue,
it shouldn't be a big deal.

However, the question also is, if it is a XML format and therefore
accepted by every parser, then it is also very likely that most (but
not all) implementations nowadays use one. Was it then ok for a RFC
to tell to use a 'restricted XML subset', or isn't that senseless
then, and the idea that token parsers could support it should be
dropped completely?

> > - 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
>
> If you only knew the pains we've had talking back and forth about this
> charset parameter. Browse mailing list archives and you'll see what I
> mean.

Ok, after greping the mbox file on that issue, I've revisited 3023.
It iniatially gave me no clue, but I then figured out that the
charset= MIME type parameter is a lot better then relying on the
<?xml encoding= attribute.

The MIME parameter is easier to parse (if the simple parser idea
survives), and I guess it even makes sense for XML-RPC to have this
setting (with its precedence), even if both the HTTP headers and the
message body are always generated on the fly (certainly never read
from disk).

And after all, the original 'spec' says nothing about charsets, so
it would be fairly ok to clearify that in a RFC.

mario

From: mario at erphesfurt.de (Mario Salzer)
Date: Tue Jan  3 16:22:40 2006
Subject: application/xml+rpc
Message-ID: <[email-masked]>

>From [email-masked] Thu Jan 15 00:59:30 2004:
> >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
> >...
> 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.

As I now read, "every stupid can write a RFC", so that's just what I'm
going to do...

> 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)

And I guess it wouldn't matter either, as there seems no reason to me
not to assign a MIME type later to something different. For example
HTML2 and HTML4 share the same MIME type!  Also if registration is
based on RFCs, then there isn't a reason not to obsolete a registration
by obsoleting such a RFC.

> It does contain a real xml document.
> ...
> >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.

Ok, XML is XML is XML. (I then almost answered that question myself.) And
obviously many documents are XML documents at a closer look:

  <Hello World="!" />

> 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.

I've noticed multiple threads about "simplified XML" on the general
XML mailing list, but again refused to download another mbox compilation
just to follow them. And after noticing that this issue was already
discussed to death there, I didn't feel the necessarity to annoy
subscribers there. (And needless to say, until there is a full XML
parser in Assembler or Brainfuck this discussion will keep on.)

But as you pointed out, it also made little sense to have another
specification just for documenting a shadow of the original format.

> 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.

So I already started a draft, which would initially just mention what
features of XML to use and which not - this seriously becomes a big
"MUST NOT" paragraph. ;)

   It's my current understanding of XML-RPC to be a dumb enough XML
   format to even allow a token parser (flex) instead of a XML parser
   or reading it.

> >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.

Hmm, possible. But won't happen. The UserLand folks (as I see it) are
not very interested in that. That's also why the XML-RPC isn't yet
RFCified.
And if they would register it in the vendor tree, you'd soon also
see:
* application/vnd.apache.rpc+xml
* application/vnd.xwt.xmc
(And one for everybody, who also interpreted the 'spec' slightly
different.)

Did the IETF or IANA make any provision against such MIME type explosions?
I think that's a serious concern, not only with this XML-RPC thing (but I
think here it was very likely to happen).

> >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.

The charset issue was discussed on the xmlrpc-dev mailing list almost
a thousand times. And still the so called 'spec' does not clearify it,
as you've seen.

Originally it mentioned "ASCII" in the table explaining the <string> type,
which led to implementations which only support or recommend 7bit chars,
and some only [\t\n\r040-0177] chars). Later UserLand introduced the
<base64> type to as one workaround. And then it was clearified that the
XML-RPC msgs are allowed to contain "binary" content (which rises the
question, why the <base64> thing then was introduced in the first place).

So the 'spec' says nothing about it. This then however would allow the
RFC to tell, that UTF-8 should be used all over.

>
> 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 <base64> is a good example, that one may choose to have UTF-8 in
the <string>s, but leave the original binary encoding within the <base64>
parts. Which would be ok from the XML point of view.

I only know of an implementation that recommended to UTF-8 encode some
<string>s and URLencoding (%41+%E1) for others. The latter ones then
could be some other charset, but then this was also ok, as they were
ciphered into an ASCII string.

However I'm almost sure, that there are also cases, where people freely
intermix encodings; because the destination RPC function would take care
of what format which function was.

>
> 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.

Exactly. However now that the <base64> is there, it won't go away.

>
> >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.

Ok, some more readings on that issue clearified the process to me. And
the RFC draft seems to be a good idea, because that userland howto is
anything but a "specification".

However, there was already an earlier attemp to do so. A draft on a
protocol called "XMC" was here until the end of 2002. (It documented
almost "XML-RPC", but because of the trademark issue was called
differently.)  I've spoken with the drafts author, and he told me he
didn't update it because of the "lack of interest" from the IETF.

It was nearly complete on documenting the message body format, but
obviously lacked a bit RFC fine tuning. However this being rejected
in the end, makes me wonder if _I_ then should risk it even if it's
interesting and appears to be in widespread use.

Best regards,
mario

From: triad at df.lth.se (Linus Walleij)
Date: Tue Jan  3 16:22:40 2006
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 12 Jan 2004, Mario Salzer wrote:

> 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/].

This is an important protocol, and you want the transport type to be
registed in the IETF tree. So write an RFC.

> 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.

The deviations are OK if described in human-readable form in an RFC. Isn't
it actually a subset of XML?

> - there is even no DTD,

But one could write one? Am I right?

> - 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

If you only knew the pains we've had talking back and forth about this
charset parameter. Browse mailing list archives and you'll see what I
mean.

Linus

From: triad at df.lth.se (Linus Walleij)
Date: Tue Jan  3 16:22:40 2006
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 12 Jan 2004, Mario Salzer wrote:

> 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/].

This is an important protocol, and you want the transport type to be
registed in the IETF tree. So write an RFC.

> 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.

The deviations are OK if described in human-readable form in an RFC. Isn't
it actually a subset of XML?

> - there is even no DTD,

But one could write one? Am I right?

> - 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

If you only knew the pains we've had talking back and forth about this
charset parameter. Browse mailing list archives and you'll see what I
mean.

Linus

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:40 2006
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
Message-ID: <4.2.0.58.J.20040114113745.05276c48@localhost>

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.

From: ben at morrow.me.uk ([email-masked])
Date: Tue Jan 13 23:39:15 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

At  2pm on 13/01/04 you (Mark Baker) wrote:
> I wanted to express my *strong* support for the recently published draft
> about the "dns" media type registration tree[1].  I think this is long
> overdue, and I thank Mark for devising such a straightforward mechanism
> for decentralizing the media type assignment process (you don't want to
> know what I was going to propose 8-).
> 
> I would like to propose one substantive change to the document though.

I would agree, both with your support for the system in general and
with your modification.

Ben

-- 
Heracles: Vulture! Here's a titbit for you / A few dried molecules of the gall
   From the liver of a friend of yours. / Excuse the arrow but I have no spoon.
(Ted Hughes,        [ Heracles shoots Vulture with arrow. Vulture bursts into ]
 /Alcestis/)        [ flame, and falls out of sight. ]         [email-masked]
>From [email-masked]  Wed Jan 14 22:51:04 2004
From: duerst at w3.org (Martin Duerst)
Date: Wed Jan 14 22:52:01 2004
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
Message-ID: <4.2.0.58.J.20040114113745.05276c48@localhost>

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.
>From [email-masked]  Fri Jan 16 02:34:06 2004
From: triad at df.lth.se (Linus Walleij)
Date: Fri Jan 16 02:34:08 2004
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 12 Jan 2004, Mario Salzer wrote:

> 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/].

This is an important protocol, and you want the transport type to be
registed in the IETF tree. So write an RFC.

> 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.

The deviations are OK if described in human-readable form in an RFC. Isn't
it actually a subset of XML?

> - there is even no DTD,

But one could write one? Am I right?

> - 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

If you only knew the pains we've had talking back and forth about this
charset parameter. Browse mailing list archives and you'll see what I
mean.

Linus
>From [email-masked]  Fri Jan 16 02:34:06 2004
From: triad at df.lth.se (Linus Walleij)
Date: Fri Jan 16 02:34:13 2004
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 12 Jan 2004, Mario Salzer wrote:

> 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/].

This is an important protocol, and you want the transport type to be
registed in the IETF tree. So write an RFC.

> 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.

The deviations are OK if described in human-readable form in an RFC. Isn't
it actually a subset of XML?

> - there is even no DTD,

But one could write one? Am I right?

> - 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

If you only knew the pains we've had talking back and forth about this
charset parameter. Browse mailing list archives and you'll see what I
mean.

Linus
>From [email-masked]  Fri Jan 16 04:57:25 2004
From: mario at erphesfurt.de (Mario Salzer)
Date: Fri Jan 16 04:58:13 2004
Subject: application/xml+rpc
Message-ID: <[email-masked]>

> This is an important protocol, and you want the transport type to be
> registed in the IETF tree. So write an RFC.
> ...
> The deviations are OK if described in human-readable form in an RFC. Isn't
> it actually a subset of XML?

Yep, I've already begun that. And as that earlier published draft
("XMC") on it provides some well written paragraphs on this issue,
it shouldn't be a big deal.

However, the question also is, if it is a XML format and therefore
accepted by every parser, then it is also very likely that most (but
not all) implementations nowadays use one. Was it then ok for a RFC
to tell to use a 'restricted XML subset', or isn't that senseless
then, and the idea that token parsers could support it should be
dropped completely?

> > - 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
>
> If you only knew the pains we've had talking back and forth about this
> charset parameter. Browse mailing list archives and you'll see what I
> mean.

Ok, after greping the mbox file on that issue, I've revisited 3023.
It iniatially gave me no clue, but I then figured out that the
charset= MIME type parameter is a lot better then relying on the
<?xml encoding= attribute.

The MIME parameter is easier to parse (if the simple parser idea
survives), and I guess it even makes sense for XML-RPC to have this
setting (with its precedence), even if both the HTTP headers and the
message body are always generated on the fly (certainly never read
from disk).

And after all, the original 'spec' says nothing about charsets, so
it would be fairly ok to clearify that in a RFC.

mario
>From [email-masked]  Fri Jan 16 04:57:10 2004
From: mario at erphesfurt.de (Mario Salzer)
Date: Fri Jan 16 04:58:18 2004
Subject: application/xml+rpc
Message-ID: <[email-masked]>

>From [email-masked] Thu Jan 15 00:59:30 2004:
> >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
> >...
> 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.

As I now read, "every stupid can write a RFC", so that's just what I'm
going to do...

> 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)

And I guess it wouldn't matter either, as there seems no reason to me
not to assign a MIME type later to something different. For example
HTML2 and HTML4 share the same MIME type!  Also if registration is
based on RFCs, then there isn't a reason not to obsolete a registration
by obsoleting such a RFC.

> It does contain a real xml document.
> ...
> >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.

Ok, XML is XML is XML. (I then almost answered that question myself.) And
obviously many documents are XML documents at a closer look:

  <Hello World="!" />

> 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.

I've noticed multiple threads about "simplified XML" on the general
XML mailing list, but again refused to download another mbox compilation
just to follow them. And after noticing that this issue was already
discussed to death there, I didn't feel the necessarity to annoy
subscribers there. (And needless to say, until there is a full XML
parser in Assembler or Brainfuck this discussion will keep on.)

But as you pointed out, it also made little sense to have another
specification just for documenting a shadow of the original format.

> 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.

So I already started a draft, which would initially just mention what
features of XML to use and which not - this seriously becomes a big
"MUST NOT" paragraph. ;)

   It's my current understanding of XML-RPC to be a dumb enough XML
   format to even allow a token parser (flex) instead of a XML parser
   or reading it.

> >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.

Hmm, possible. But won't happen. The UserLand folks (as I see it) are
not very interested in that. That's also why the XML-RPC isn't yet
RFCified.
And if they would register it in the vendor tree, you'd soon also
see:
* application/vnd.apache.rpc+xml
* application/vnd.xwt.xmc
(And one for everybody, who also interpreted the 'spec' slightly
different.)

Did the IETF or IANA make any provision against such MIME type explosions?
I think that's a serious concern, not only with this XML-RPC thing (but I
think here it was very likely to happen).

> >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.

The charset issue was discussed on the xmlrpc-dev mailing list almost
a thousand times. And still the so called 'spec' does not clearify it,
as you've seen.

Originally it mentioned "ASCII" in the table explaining the <string> type,
which led to implementations which only support or recommend 7bit chars,
and some only [\t\n\r040-0177] chars). Later UserLand introduced the
<base64> type to as one workaround. And then it was clearified that the
XML-RPC msgs are allowed to contain "binary" content (which rises the
question, why the <base64> thing then was introduced in the first place).

So the 'spec' says nothing about it. This then however would allow the
RFC to tell, that UTF-8 should be used all over.

>
> 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 <base64> is a good example, that one may choose to have UTF-8 in
the <string>s, but leave the original binary encoding within the <base64>
parts. Which would be ok from the XML point of view.

I only know of an implementation that recommended to UTF-8 encode some
<string>s and URLencoding (%41+%E1) for others. The latter ones then
could be some other charset, but then this was also ok, as they were
ciphered into an ASCII string.

However I'm almost sure, that there are also cases, where people freely
intermix encodings; because the destination RPC function would take care
of what format which function was.

>
> 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.

Exactly. However now that the <base64> is there, it won't go away.

>
> >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.

Ok, some more readings on that issue clearified the process to me. And
the RFC draft seems to be a good idea, because that userland howto is
anything but a "specification".

However, there was already an earlier attemp to do so. A draft on a
protocol called "XMC" was here until the end of 2002. (It documented
almost "XML-RPC", but because of the trademark issue was called
differently.)  I've spoken with the drafts author, and he told me he
didn't update it because of the "lack of interest" from the IETF.

It was nearly complete on documenting the message body format, but
obviously lacked a bit RFC fine tuning. However this being rejected
in the end, makes me wonder if _I_ then should risk it even if it's
interesting and appears to be in widespread use.

Best regards,
mario
>From [email-masked]  Fri Jan 16 19:27:41 2004
From: LMM at acm.org (Larry Masinter)
Date: Fri Jan 16 19:29:25 2004
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
Message-ID: <[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

From: ben at morrow.me.uk ([email-masked])
Date: Tue Jan  3 16:22:39 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

At  2pm on 13/01/04 you (Mark Baker) wrote:
> I wanted to express my *strong* support for the recently published draft
> about the "dns" media type registration tree[1].  I think this is long
> overdue, and I thank Mark for devising such a straightforward mechanism
> for decentralizing the media type assignment process (you don't want to
> know what I was going to propose 8-).
> 
> I would like to propose one substantive change to the document though.

I would agree, both with your support for the system in general and
with your modification.

Ben

-- 
Heracles: Vulture! Here's a titbit for you / A few dried molecules of the gall
   From the liver of a friend of yours. / Excuse the arrow but I have no spoon.
(Ted Hughes,        [ Heracles shoots Vulture with arrow. Vulture bursts into ]
 /Alcestis/)        [ flame, and falls out of sight. ]         [email-masked]

From: LMM at acm.org (Larry Masinter)
Date: Tue Jan  3 16:22:39 2006
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I'm wondering if we should consider a similar DNS-basis
for "private" URI schemes.  I've been late in producing
a new version of 

http://www.ietf.org/internet-drafts/draft-king-vnd-urlscheme-03.txt

partly because of my uneasiness with IANA getting into the
business of registering organization names.

Larry

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Baker
> Sent: Tuesday, January 13, 2004 11:16 AM
> To: [email-masked]
> Subject: dns media type registration tree
> 
> Hi,
> 
> I wanted to express my *strong* support for the recently 
> published draft
> about the "dns" media type registration tree[1].  I think this is long
> overdue, and I thank Mark for devising such a straightforward 
> mechanism
> for decentralizing the media type assignment process (you 
> don't want to
> know what I was going to propose 8-).
> 
> I would like to propose one substantive change to the document though.
> 
> As I see it, there are two objectives that we'd really like 
> to achieve;
> a decentralized namespace, and dereferenceable identifiers 
> (for all the
> reasons in [2]).  Mark's draft ably addresses the former, but doesn't
> seem to treat the latter as an objective, although the "doc" parameter
> is a step in that direction.  I think a fairly small tweak can give us
> both.
> 
> What I propose is that the doc parameter be replaced by a "base"
> parameter whose value is a URI that is intended to permit the media
> type name itself to be used as a relative URI.  For example, if we had
> the media type "text/dns.foo.example.com", with a base parameter value
> of "http://example.com/mtype/" then the authoritative URI for 
> the media
> type would be "http://example.com/mtype/text/dns.foo.example.com"
> (see the discussion[3] about the relative URI approach by the 
> W3C TAG).
> The document should be clear that the resultant URI is the 
> authoritative
> URI for the media type.  It would still be optional, though 
> I'd like to
> say that we recommend that it SHOULD be used, and SHOULD be
> dereferenceable using currently ubiquitous technologies.
> 
> Thoughts?
> 
>  [1] 
> http://www.ietf.org/internet-drafts/draft-nottingham-dns-media
-tree-00.txt
>  [2] 
> http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessi
ble-registries-00.txt
>  [3] http://www.w3.org/2003/12/15-tag-summary.html#uriMediaType-9
> 
> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> 

From: distobj at acm.org (Mark Baker)
Date: Tue Jan  3 16:22:39 2006
Subject: dns media type registration tree
Message-ID: <[email-masked]>

Hi,

I wanted to express my *strong* support for the recently published draft
about the "dns" media type registration tree[1].  I think this is long
overdue, and I thank Mark for devising such a straightforward mechanism
for decentralizing the media type assignment process (you don't want to
know what I was going to propose 8-).

I would like to propose one substantive change to the document though.

As I see it, there are two objectives that we'd really like to achieve;
a decentralized namespace, and dereferenceable identifiers (for all the
reasons in [2]).  Mark's draft ably addresses the former, but doesn't
seem to treat the latter as an objective, although the "doc" parameter
is a step in that direction.  I think a fairly small tweak can give us
both.

What I propose is that the doc parameter be replaced by a "base"
parameter whose value is a URI that is intended to permit the media
type name itself to be used as a relative URI.  For example, if we had
the media type "text/dns.foo.example.com", with a base parameter value
of "http://example.com/mtype/" then the authoritative URI for the media
type would be "http://example.com/mtype/text/dns.foo.example.com"
(see the discussion[3] about the relative URI approach by the W3C TAG).
The document should be clear that the resultant URI is the authoritative
URI for the media type.  It would still be optional, though I'd like to
say that we recommend that it SHOULD be used, and SHOULD be
dereferenceable using currently ubiquitous technologies.

Thoughts?

 [1] http://www.ietf.org/internet-drafts/draft-nottingham-dns-media-tree-00.txt
 [2] http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessible-registries-00.txt
 [3] http://www.w3.org/2003/12/15-tag-summary.html#uriMediaType-9

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

From: mnot at mnot.net (Mark Nottingham)
Date: Tue Jan 13 02:16:50 2004
Subject: FYI: draft-nottingham-dns-media-tree-00
Message-ID: <[email-masked]>

I've written an I-D proposing a new tree for media types. Comments and  
suggestions appreciated.

See:
    
http://www.ietf.org/internet-drafts/draft-nottingham-dns-media-tree 
-00.txt

Regards,

--
Mark Nottingham     http://www.mnot.net/

From: mnot at mnot.net (Mark Nottingham)
Date: Tue Jan  3 16:22:39 2006
Subject: FYI: draft-nottingham-dns-media-tree-00
Message-ID: <[email-masked]>

I've written an I-D proposing a new tree for media types. Comments and  
suggestions appreciated.

See:
    
http://www.ietf.org/internet-drafts/draft-nottingham-dns-media-tree 
-00.txt

Regards,

--
Mark Nottingham     http://www.mnot.net/

From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Tue Jan  3 16:22:39 2006
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[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]>

From: mario at erphesfurt.de (Mario Salzer)
Date: Tue Jan 13 14:13:28 2004
Subject: application/xml+rpc
Message-ID: <[email-masked]>

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.

> 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.

> ...
> 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.
> ...
> Ah, so it's still XML, but not all XML would work for xml-rpc.

Yes, personally I don't use a XML parser to parse XML-RPC messages. And as I
see it, the "XML" in "XML-RPC" is just a buzzword. Moreover I would say
XML-RPC messages are only "using XML-like tokens" for making RPC calls
readable. Even if in fact the tokens make up validly nested XML tags, and
the <?xml...?> prefix then even allows to use XML-RPC messages with
non-validating XML parsers.

> 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.

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?
So of course the /xml+rpc is out of discussion, if only things like
+xml +sgml and +yaml are to be used as generic suffixes.

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?

> MURATA Makoto <[email-masked]> wrote:
> 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.

I doubt that anything but a proxy will ever see such a XML-RPC message,
but who knows? And yes, there is absolutely no reason to _forbid_ anyone
to use a XML aware software (parser) on it - and actually this is
explicetely wanted (expressed in the <?xml...?> message prefix).

> 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. 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?
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).

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.

> >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] 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. 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).
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.
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".

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. 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).

> >- XML-RPC currently only operates on HTTP, so no need to take Mail protos
> >   into account
>
> What do you mean by "Mail protos"?

Currently XML-RPC only is supposed to work over HTTP, but I guess it would
be possible to use it over SMTP (but there would be no application for this,
and it wouldn't be widely used either).

> >- 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?

Regards,
mario
>From [email-masked]  Tue Jan 13 20:16:05 2004
From: distobj at acm.org (Mark Baker)
Date: Tue Jan 13 20:19:26 2004
Subject: dns media type registration tree
Message-ID: <[email-masked]>

Hi,

I wanted to express my *strong* support for the recently published draft
about the "dns" media type registration tree[1].  I think this is long
overdue, and I thank Mark for devising such a straightforward mechanism
for decentralizing the media type assignment process (you don't want to
know what I was going to propose 8-).

I would like to propose one substantive change to the document though.

As I see it, there are two objectives that we'd really like to achieve;
a decentralized namespace, and dereferenceable identifiers (for all the
reasons in [2]).  Mark's draft ably addresses the former, but doesn't
seem to treat the latter as an objective, although the "doc" parameter
is a step in that direction.  I think a fairly small tweak can give us
both.

What I propose is that the doc parameter be replaced by a "base"
parameter whose value is a URI that is intended to permit the media
type name itself to be used as a relative URI.  For example, if we had
the media type "text/dns.foo.example.com", with a base parameter value
of "http://example.com/mtype/" then the authoritative URI for the media
type would be "http://example.com/mtype/text/dns.foo.example.com"
(see the discussion[3] about the relative URI approach by the W3C TAG).
The document should be clear that the resultant URI is the authoritative
URI for the media type.  It would still be optional, though I'd like to
say that we recommend that it SHOULD be used, and SHOULD be
dereferenceable using currently ubiquitous technologies.

Thoughts?

 [1] http://www.ietf.org/internet-drafts/draft-nottingham-dns-media-tree-00.txt
 [2] http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessible-registries-00.txt
 [3] http://www.w3.org/2003/12/15-tag-summary.html#uriMediaType-9

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>From [email-masked]  Tue Jan 13 20:49:27 2004
From: LMM at acm.org (Larry Masinter)
Date: Tue Jan 13 20:49:45 2004
Subject: dns media type registration tree
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

I'm wondering if we should consider a similar DNS-basis
for "private" URI schemes.  I've been late in producing
a new version of 

http://www.ietf.org/internet-drafts/draft-king-vnd-urlscheme-03.txt

partly because of my uneasiness with IANA getting into the
business of registering organization names.

Larry

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Baker
> Sent: Tuesday, January 13, 2004 11:16 AM
> To: [email-masked]
> Subject: dns media type registration tree
> 
> Hi,
> 
> I wanted to express my *strong* support for the recently 
> published draft
> about the "dns" media type registration tree[1].  I think this is long
> overdue, and I thank Mark for devising such a straightforward 
> mechanism
> for decentralizing the media type assignment process (you 
> don't want to
> know what I was going to propose 8-).
> 
> I would like to propose one substantive change to the document though.
> 
> As I see it, there are two objectives that we'd really like 
> to achieve;
> a decentralized namespace, and dereferenceable identifiers 
> (for all the
> reasons in [2]).  Mark's draft ably addresses the former, but doesn't
> seem to treat the latter as an objective, although the "doc" parameter
> is a step in that direction.  I think a fairly small tweak can give us
> both.
> 
> What I propose is that the doc parameter be replaced by a "base"
> parameter whose value is a URI that is intended to permit the media
> type name itself to be used as a relative URI.  For example, if we had
> the media type "text/dns.foo.example.com", with a base parameter value
> of "http://example.com/mtype/" then the authoritative URI for 
> the media
> type would be "http://example.com/mtype/text/dns.foo.example.com"
> (see the discussion[3] about the relative URI approach by the 
> W3C TAG).
> The document should be clear that the resultant URI is the 
> authoritative
> URI for the media type.  It would still be optional, though 
> I'd like to
> say that we recommend that it SHOULD be used, and SHOULD be
> dereferenceable using currently ubiquitous technologies.
> 
> Thoughts?
> 
>  [1] 
> http://www.ietf.org/internet-drafts/draft-nottingham-dns-media
-tree-00.txt
>  [2] 
> http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessi
ble-registries-00.txt
>  [3] http://www.w3.org/2003/12/15-tag-summary.html#uriMediaType-9
> 
> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> 

From: mario at erphesfurt.de (Mario Salzer)
Date: Tue Jan  3 16:22:39 2006
Subject: application/xml+rpc
Message-ID: <[email-masked]>

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.

> 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.

> ...
> 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.
> ...
> Ah, so it's still XML, but not all XML would work for xml-rpc.

Yes, personally I don't use a XML parser to parse XML-RPC messages. And as I
see it, the "XML" in "XML-RPC" is just a buzzword. Moreover I would say
XML-RPC messages are only "using XML-like tokens" for making RPC calls
readable. Even if in fact the tokens make up validly nested XML tags, and
the <?xml...?> prefix then even allows to use XML-RPC messages with
non-validating XML parsers.

> 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.

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?
So of course the /xml+rpc is out of discussion, if only things like
+xml +sgml and +yaml are to be used as generic suffixes.

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?

> MURATA Makoto <[email-masked]> wrote:
> 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.

I doubt that anything but a proxy will ever see such a XML-RPC message,
but who knows? And yes, there is absolutely no reason to _forbid_ anyone
to use a XML aware software (parser) on it - and actually this is
explicetely wanted (expressed in the <?xml...?> message prefix).

> 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. 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?
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).

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.

> >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] 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. 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).
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.
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".

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. 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).

> >- XML-RPC currently only operates on HTTP, so no need to take Mail protos
> >   into account
>
> What do you mean by "Mail protos"?

Currently XML-RPC only is supposed to work over HTTP, but I guess it would
be possible to use it over SMTP (but there would be no application for this,
and it wouldn't be widely used either).

> >- 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?

Regards,
mario

From: duerst at w3.org (Martin Duerst)
Date: Mon Jan 12 17:53:24 2004
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
Message-ID: <4.2.0.58.J.20040112112035.056c9f68@localhost>

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.
>From [email-masked]  Tue Jan 13 01:55:28 2004
From: murata at hokkaido.email.ne.jp (MURATA Makoto)
Date: Tue Jan 13 01:59:24 2004
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[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]>

From: duerst at w3.org (Martin Duerst)
Date: Tue Jan  3 16:22:39 2006
Subject: application/xml+rpc
In-Reply-To: <[email-masked]>
Message-ID: <4.2.0.58.J.20040112112035.056c9f68@localhost>

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.

From: mario at erphesfurt.de (Mario Salzer)
Date: Mon Jan 12 09:38:56 2004
Subject: application/xml+rpc
Message-ID: <[email-masked]>

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), 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.
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).

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.

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)

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

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)

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
- 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
- security seems no issue for requesting this MIME type - at best handled
  at HTTP level (Basic Auth or Cookies)

Best regards,
mario

From: mario at erphesfurt.de (Mario Salzer)
Date: Mon Jan 12 09:39:09 2004
Subject: application/xml+rpc
Message-ID: <[email-masked]>

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), 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.
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).

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.

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)

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

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)

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
- 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
- security seems no issue for requesting this MIME type - at best handled
  at HTTP level (Basic Auth or Cookies)

Best regards,
mario

From: mario at erphesfurt.de (Mario Salzer)
Date: Tue Jan  3 16:22:39 2006
Subject: application/xml+rpc
Message-ID: <[email-masked]>

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), 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.
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).

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.

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)

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

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)

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
- 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
- security seems no issue for requesting this MIME type - at best handled
  at HTTP level (Basic Auth or Cookies)

Best regards,
mario