From: iana at iana.org (iana@iana.org) Date: Sat Jan 24 13:57:21 2004 Subject: Hi Message-ID: 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 mario@erphesfurt.de 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: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> 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 whateverFuntion I'm the first parameter 2 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 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 (iana@iana.org) Date: Tue Jan 3 16:22:40 2006 Subject: Hi Message-ID: 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 (iana@iana.org) Date: Tue Jan 20 05:49:53 2004 Subject: Hi Message-ID: 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 iana@iana.org Tue Jan 20 07:54:19 2004 From: iana at iana.org (iana@iana.org) Date: Tue Jan 20 08:02:34 2004 Subject: Hi Message-ID: 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 iana@iana.org Tue Jan 20 10:25:33 2004 From: iana at iana.org (iana@iana.org) Date: Tue Jan 20 10:17:01 2004 Subject: Hi Message-ID: 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 iana@iana.org Tue Jan 20 11:56:51 2004 From: iana at iana.org (iana@iana.org) Date: Tue Jan 20 11:56:50 2004 Subject: Hi Message-ID: 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 mark.nottingham@bea.com 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: <2790F81B-4D14-11D8-8F32-00039396E15A@bea.com> 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 (iana@iana.org) Date: Tue Jan 3 16:22:40 2006 Subject: Hi Message-ID: 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 iana@iana.org Tue Jan 20 07:54:19 2004 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:40 2006 Subject: Hi Message-ID: 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 iana@iana.org Tue Jan 20 10:25:33 2004 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:40 2006 Subject: Hi Message-ID: 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 iana@iana.org Tue Jan 20 11:56:51 2004 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:40 2006 Subject: Hi Message-ID: 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 mark.nottingham@bea.com 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: <2790F81B-4D14-11D8-8F32-00039396E15A@bea.com> 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: <4009A9B9.nail34C1X5JDY@yoco.erphesfurt.de> Message-ID: <0HRR00BSRLWNTH@mailsj-v1.corp.adobe.com> > > 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 ietf-xml-use@imc.org (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: <4009A9B9.nail34C1X5JDY@yoco.erphesfurt.de> Message-ID: <0HRR00BSRLWNTH@mailsj-v1.corp.adobe.com> > > 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 ietf-xml-use@imc.org (the mailing list set up for the 'xml use' RFC) would be the right venue. Larry From: iana at iana.org (iana@iana.org) Date: Mon Jan 19 09:45:56 2004 Subject: Hi Message-ID: 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 iana@iana.org Mon Jan 19 10:31:15 2004 From: iana at iana.org (iana@iana.org) Date: Mon Jan 19 10:31:19 2004 Subject: Hi Message-ID: 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 LMM@acm.org 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: <0HRR00BCBJODTH@mailsj-v1.corp.adobe.com> 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 (iana@iana.org) Date: Tue Jan 3 16:22:40 2006 Subject: Hi Message-ID: 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 iana@iana.org Mon Jan 19 10:31:15 2004 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:40 2006 Subject: Hi Message-ID: 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 LMM@acm.org 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: <0HRR00BCBJODTH@mailsj-v1.corp.adobe.com> 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 (iana@iana.org) Date: Tue Jan 3 16:22:40 2006 Subject: Hi Message-ID: 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 iana@iana.org Mon Jan 19 07:06:43 2004 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:40 2006 Subject: Hi Message-ID: 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 iana@iana.org Mon Jan 19 08:10:41 2004 From: iana at iana.org (iana@iana.org) Date: Tue Jan 3 16:22:40 2006 Subject: Hi Message-ID: 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 technik@willms-edv.de 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: On Mon, 19 Jan 2004 14:19:40 +0900, iana@iana.org wrote: > Received: from w6t7z7 ([221.163.136.159]) > by pechora.icann.org (8.11.6/8.11.6) with SMTP id i0J5Lu812344 > for ; Sun, 18 Jan 2004 21:21:56 -0800 > Date: Mon, 19 Jan 2004 14:19:40 +0900 > To: ietf-types@iana.org > From: iana@iana.org > Message-ID: > MIME-Version: 1.0 > Content-Type: multipart/mixed; > boundary="--------257380553721802" > Cc: > Subject: Hi > X-BeenThere: ietf-types@alvestrand.no ... > Sender: ietf-types-bounces@alvestrand.no > Errors-To: ietf-types-bounces@alvestrand.no > > 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: <0HRL00A1CHY5JG@mailsj-v1.corp.adobe.com> References: <0HRL00A1CHY5JG@mailsj-v1.corp.adobe.com> Message-ID: <4009A9B9.nail34C1X5JDY@yoco.erphesfurt.de> > 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 iana@iana.org Mon Jan 19 06:19:40 2004 From: iana at iana.org (iana@iana.org) Date: Mon Jan 19 06:20:00 2004 Subject: Hi Message-ID: 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 iana@iana.org Mon Jan 19 07:06:43 2004 From: iana at iana.org (iana@iana.org) Date: Mon Jan 19 07:03:25 2004 Subject: Hi Message-ID: 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 iana@iana.org Mon Jan 19 08:10:41 2004 From: iana at iana.org (iana@iana.org) Date: Mon Jan 19 08:08:49 2004 Subject: Hi Message-ID: 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 technik@willms-edv.de 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: On Mon, 19 Jan 2004 14:19:40 +0900, iana@iana.org wrote: > Received: from w6t7z7 ([221.163.136.159]) > by pechora.icann.org (8.11.6/8.11.6) with SMTP id i0J5Lu812344 > for ; Sun, 18 Jan 2004 21:21:56 -0800 > Date: Mon, 19 Jan 2004 14:19:40 +0900 > To: ietf-types@iana.org > From: iana@iana.org > Message-ID: > MIME-Version: 1.0 > Content-Type: multipart/mixed; > boundary="--------257380553721802" > Cc: > Subject: Hi > X-BeenThere: ietf-types@alvestrand.no ... > Sender: ietf-types-bounces@alvestrand.no > Errors-To: ietf-types-bounces@alvestrand.no > > 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: <0HRL00A1CHY5JG@mailsj-v1.corp.adobe.com> References: <0HRL00A1CHY5JG@mailsj-v1.corp.adobe.com> Message-ID: <4009A9B9.nail34C1X5JDY@yoco.erphesfurt.de> > 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: <40076116.nailMWP115EKL@yoco.erphesfurt.de> Message-ID: <0HRL00A1CHY5JG@mailsj-v1.corp.adobe.com> 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: <40076125.nailMWT11NA11@yoco.erphesfurt.de> > 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 >From duerst@w3.org 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: > 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 type, which led to implementations which only support or recommend 7bit chars, and some only [\t\n\r040-0177] chars). Later UserLand introduced the 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 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 is a good example, that one may choose to have UTF-8 in the s, but leave the original binary encoding within the parts. Which would be ok from the XML point of view. I only know of an implementation that recommended to UTF-8 encode some 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 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: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> References: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> Message-ID: 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: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> References: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> Message-ID: 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: <40033A3A.nailK311D4TX@yoco.erphesfurt.de> 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 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 > 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 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 ...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 >...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 >parameter inside of the messages. [That would be ] >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 (ben@morrow.me.uk) Date: Tue Jan 13 23:39:15 2004 Subject: dns media type registration tree In-Reply-To: <20040113141605.A1228@www.markbaker.ca> References: <20040113141605.A1228@www.markbaker.ca> Message-ID: <20040113223908.GA5872@mauzo.mauzo.dyndns.org> 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. ] ben@morrow.me.uk >From duerst@w3.org 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: <40033A3A.nailK311D4TX@yoco.erphesfurt.de> 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 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 > 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 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 ...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 >...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 >parameter inside of the messages. [That would be ] >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 triad@df.lth.se 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: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> References: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> Message-ID: 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@df.lth.se 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: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> References: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> Message-ID: 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 mario@erphesfurt.de 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: <40076125.nailMWT11NA11@yoco.erphesfurt.de> > 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 From mario@erphesfurt.de 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: <40076116.nailMWP115EKL@yoco.erphesfurt.de> >From duerst@w3.org 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: > 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 type, which led to implementations which only support or recommend 7bit chars, and some only [\t\n\r040-0177] chars). Later UserLand introduced the 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 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 is a good example, that one may choose to have UTF-8 in the s, but leave the original binary encoding within the parts. Which would be ok from the XML point of view. I only know of an implementation that recommended to UTF-8 encode some 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 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 LMM@acm.org 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: <40076116.nailMWP115EKL@yoco.erphesfurt.de> Message-ID: <0HRL00A1CHY5JG@mailsj-v1.corp.adobe.com> 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 (ben@morrow.me.uk) Date: Tue Jan 3 16:22:39 2006 Subject: dns media type registration tree In-Reply-To: <20040113141605.A1228@www.markbaker.ca> References: <20040113141605.A1228@www.markbaker.ca> Message-ID: <20040113223908.GA5872@mauzo.mauzo.dyndns.org> 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. ] ben@morrow.me.uk From: LMM at acm.org (Larry Masinter) Date: Tue Jan 3 16:22:39 2006 Subject: dns media type registration tree In-Reply-To: <20040113141605.A1228@www.markbaker.ca> Message-ID: <0HRG00MNY1QI9Y@mailsj-v1.corp.adobe.com> 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: ietf-types-bounces@alvestrand.no > [mailto:ietf-types-bounces@alvestrand.no] On Behalf Of Mark Baker > Sent: Tuesday, January 13, 2004 11:16 AM > To: ietf-types@alvestrand.no > 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: <20040113141605.A1228@www.markbaker.ca> 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: <27B5F1CE-4566-11D8-87FF-00039396E15A@mnot.net> 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: <27B5F1CE-4566-11D8-87FF-00039396E15A@mnot.net> 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: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> References: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> Message-ID: <20040113093716.79B4.MURATA@hokkaido.email.ne.jp> 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 From: mario at erphesfurt.de (Mario Salzer) Date: Tue Jan 13 14:13:28 2004 Subject: application/xml+rpc Message-ID: <40033A3A.nailK311D4TX@yoco.erphesfurt.de> 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 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 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 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 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 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 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 ...... 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 distobj@acm.org 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: <20040113141605.A1228@www.markbaker.ca> 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 LMM@acm.org 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: <20040113141605.A1228@www.markbaker.ca> Message-ID: <0HRG00MNY1QI9Y@mailsj-v1.corp.adobe.com> 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: ietf-types-bounces@alvestrand.no > [mailto:ietf-types-bounces@alvestrand.no] On Behalf Of Mark Baker > Sent: Tuesday, January 13, 2004 11:16 AM > To: ietf-types@alvestrand.no > 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: <40033A3A.nailK311D4TX@yoco.erphesfurt.de> 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 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 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 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 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 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 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 ...... 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: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> 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 > > > > whateverFuntion > > I'm the first > parameter > 2 > > > >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 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.: ietf-types@alvestrand.no and ietf-types@iana.org are the same list. But ietf-xml-mime@imc.org is a separate list, which I'm cross- posting because you might get valuable feedback from there. >From murata@hokkaido.email.ne.jp 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: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> References: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> Message-ID: <20040113093716.79B4.MURATA@hokkaido.email.ne.jp> 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 From: duerst at w3.org (Martin Duerst) Date: Tue Jan 3 16:22:39 2006 Subject: application/xml+rpc In-Reply-To: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> 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 > > > > whateverFuntion > > I'm the first > parameter > 2 > > > >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 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.: ietf-types@alvestrand.no and ietf-types@iana.org are the same list. But ietf-xml-mime@imc.org 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: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> 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 whateverFuntion I'm the first parameter 2 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 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: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> 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 whateverFuntion I'm the first parameter 2 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 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: <40025CEB.nailQA11QUL5@yoco.erphesfurt.de> 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 whateverFuntion I'm the first parameter 2 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 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