Re: Request for some quick guidance on XMLP Issue 269

Hello Noah,

Many thanks for contacting me. Unfortunately, Wednesday/Thursday,
I was on a flight back from Boston to Tokyo.

At 15:27 02/07/31 -0400, wrote:

>The XMLP WG is meeting FTF today and tomorrow, and we are considering an 
>issue raised in your email [1] and tagged as our issue 269 [2].  If it's 
>not too inconvenient, we were wondering whether we might impose on you to 
>give us a quick clarification, preferably in time for consideration on 
>Thursday, West Coast US time.
>You quote our spec:
> >> response MAY be of content type other than
> >> application/soap+xml:
>and suggest
> >> add a note saying that care
> >> is needed because different content types may have
> >> different rules for the 'charset' parameter.
>We're not 100% sure we understand the concern.  Note that the full quote 
>from our spec is:
>"The response MAY be of content type other than "application/soap+xml". 
>Such a result is particularly likely when a SOAP request sent with a 
>webmeth:Method of "GET" is directed (intentionally or otherwise) to a 
>non-SOAP HTTP server. Such usage is considered non-normative, and 
>accordingly is not modeled in the state machine above. Interpretation of 
>such responses is at the discretion of the receiver."
>You appear to be asking for a health warning regarding a mode of use that 
>we specifically decline to make normative, and for which we deline to 
>specify any really detailed semantics even non-normatively.  The WG has 
>not reached the point of formulating a response, but instead wanted to be 
>sure that we hadn't missed any aspect of your concern.  If you could 
>clarify the cases that are of interest, which of them you believe to be 
>normative, and whether you indeed are looking for health warnings 
>regarding the non-normative cases, that would be very helpful.

I'm indeed looking for a health warning re. non-normative cases.
I think the chance that somebody implements application/soap+xml,
where there is no 'charset' default, and therefore the rules of
Appendix F of XML ( apply,
and then thinks they can add more types, for example text/xml,...
and they don't take care of the fact that in that case, the default
is us-ascii (i.e. all documents that don't come with a charset
parameter but are of type text/xml have to be treated as us-ascii),
is quite a realistic case.

Please note that the non-normative aspect is just whether a
SOAP processor supports any types apart from application/soap+xml.
If it indeed supports such types, then the handling of 'charset'
defaults is normative for each type. In than sense, the sentence
"Interpretation of such responses is at the discretion of the receiver."
may be misleading, because it somehow suggests that the receiver can do
whatever it wants. It should be made clear that the receiver
can choose to accept or not any given type, but not to mis-
interpret things.

I have copied the I18N IG.

Regards,    Martin.

>Thank you very much.
>Noah Mendelsohn                              Voice: 1-617-693-4036
>IBM Corporation                                Fax: 1-617-693-8676
>One Rogers Street
>Cambridge, MA 02142

Received on Friday, 2 August 2002 03:34:16 UTC