> This is an important protocol, and you want the transport type to be
> registed in the IETF tree. So write an RFC.
> ...
> The deviations are OK if described in human-readable form in an RFC. Isn't
> it actually a subset of XML?
Yep, I've already begun that. And as that earlier published draft
("XMC") on it provides some well written paragraphs on this issue,
it shouldn't be a big deal.
However, the question also is, if it is a XML format and therefore
accepted by every parser, then it is also very likely that most (but
not all) implementations nowadays use one. Was it then ok for a RFC
to tell to use a 'restricted XML subset', or isn't that senseless
then, and the idea that token parsers could support it should be
dropped completely?
> > - there should be no charset= attribute to that MIME type, the XML-RPC
> > spec is about keeping it simple, and letting such "minor" details be
> > handled by the actual web service API specification and implementation
>
> If you only knew the pains we've had talking back and forth about this
> charset parameter. Browse mailing list archives and you'll see what I
> mean.
Ok, after greping the mbox file on that issue, I've revisited 3023.
It iniatially gave me no clue, but I then figured out that the
charset= MIME type parameter is a lot better then relying on the
<?xml encoding= attribute.
The MIME parameter is easier to parse (if the simple parser idea
survives), and I guess it even makes sense for XML-RPC to have this
setting (with its precedence), even if both the HTTP headers and the
message body are always generated on the fly (certainly never read
from disk).
And after all, the original 'spec' says nothing about charsets, so
it would be fairly ok to clearify that in a RFC.
mario
