headers
Martin Duerst | 12 Jan 2004 17:53
Picon
Favicon

Re: application/xml+rpc


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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
MURATA Makoto | 13 Jan 2004 01:55
Picon

Re: application/xml+rpc


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 <murata <at> hokkaido.email.ne.jp>
Permalink | Reply | 0 comments |
headers
Martin Duerst | 14 Jan 2004 22:51
Picon
Favicon

Re: application/xml+rpc


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 <duerst <at> w3.org> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Larry Masinter | 16 Jan 2004 19:27
Picon
Favicon

RE: application/xml+rpc


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
Permalink | Reply | 0 comments |
headers
Larry Masinter | 20 Jan 2004 02:38
Picon
Favicon

RE: application/xml+rpc


> > 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 <at> imc.org (the mailing list
set up for the 'xml use' RFC) would be the right venue.

Larry
Permalink | Reply | 0 comments |
headers
Mark Baker | 22 Jan 2004 05:26
Picon
Favicon
Gravatar

Application dispatch for application/xml


Greetings,

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

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

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

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

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

Thanks.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Martin Duerst | 25 Jan 2004 19:35
Picon
Favicon

Re: Application dispatch for application/xml


Hello Mark,

Great to see your work.

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

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

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

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

Permalink | Reply | 1 comment |
headers
Mark Baker | 26 Jan 2004 03:38
Picon
Favicon
Gravatar

Re: Application dispatch for application/xml


Hi Martin, thanks for the feedback.

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

Sorry, I thought that was implied.

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

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

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

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

Permalink | Reply | 0 comments |
headers
Chris Lilley | 27 Jan 2004 18:23
Picon
Favicon

Test


Hello ietf-xml-mime,

  Test, please ignore

--

-- 
 Chris                          mailto:chris <at> w3.org
Permalink | Reply | 0 comments |
headers
Chris Lilley | 27 Jan 2004 19:10
Picon
Favicon

Opera results for dispatch tests, plus comments and new test.


Hello Mark,

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

Test 1

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

Test 2

Displayed as (X)HTML with working link

Test 3

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

Test 4

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

Test 5

Displayed as X(HTML). "identity transformed" is emphasized. Since
there is only one element, hard to tell if the elements are being
(Continue reading)

Permalink | Reply | 0 comments |

Gmane