RE: Closing XML Protocol Last Call issue 395

I mostly agree.  I never meant to constrain the message infoset as a local 
application might see it.  On the other hand, we then take the Infoset and 
say (via RFC 3203)  "serialize it in the obvious XML 1.x manner".  In that 
case, it's very important that anything that we don't explicitly allow is 
in fact not serialized into the transmitted message.  Remember too, my 
proposal was not to say that the entries in the infoset couldn't exist (as 
you say, that's not our business.)  What I said was:  if present, they 
have no effect on SOAP processing model or transmitted data.  I still 
think that's right.

>> Just to clarify, I think the concern is 
>> with respect to the definition
>> of the "application/soap+xml" media type 
>> that defines the only encoding
>> provided by us of the SOAP message infoset.

My question is, does it provide a unique encoding (modulo, say, 
insignificant whitespace) or does it allow wiggle room for you to 
introduce a <!DOCTYPE > while serializing.  As mentioned in my note to 
Gudge a minute ago, I think there are some DTD constructions that are not 
visible in the infoset (parsed entity declarations, attribute declarations 
w/ defaults).  I don't see 3203 as prohibiting their introduction into the 
serialization, and that's my problem.  If my concern is justified, I think 
we close the hole by saying:  "Use the application/soap+xml media type, 
being sure not to include a <!DOCTYPE>."  Or, if we want to disallow it in 
the media type (which would take application/soap+xml further from 
application/xml, but would otherwise be OK with me), that would be OK too.

I hope I'm not flogging all this based on a misunderstanding, but if it is 
indeed a hole, it's a very significant one for interop.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Henrik Frystyk Nielsen" <henrikn@microsoft.com>
12/05/2002 02:26 PM

 
        To:     <noah_mendelsohn@us.ibm.com>
        cc:     "Martin Gudgin" <mgudgin@microsoft.com>, <xml-dist-app@w3.org>
        Subject:        RE: Closing XML Protocol Last Call issue 395



>Exactly my concern.  I think we should rule this out clearly 
>and unambigously in the HTTP binding and or the RFC, as 
>appopriate.  We should NOT rule out the possibility that 
>someone would do this in other bindings, as it's a potentially 
>reasonable compression trick

Just to clarify, I think the concern is with respect to the definition
of the "application/soap+xml" media type that defines the only encoding
provided by us of the SOAP message infoset. This media type is of course
*used* by the HTTP binding but is otherwise independent from the HTTP
binding. 

>I'm less worried about that, as in many critical situations 
>we're fairly clear that the Infoset for a message must contain 
>ONLY what we call for. 
>If there's any doubt, then we should put in an appropriate 
>general indication to that effect, I think (though we should 
>be a bit careful not to gratiutiously rule out things like 
>PSVI...I would probably say something like "Infoset items not 
>explicitly provided for here SHOULD NOT appear;  if they do 
>appear, they MUST NOT affect the results of SOAP processing or 
>message transmission."  In other words, don't act on them, 
>don't transmit them.  Make sense?

Not sure as this seems to imply that there is some notion of
implementation-based conformance to the infoset which is not the case.
The infoset only talks about conformance in the context of
specifications.

In addition, the infoset does not provide any notion of filtering or
transformation and hence it is not, IMO, possible to talk about infoset
properties not being exposed to the application: if a property is
present then it is exposed. Given that the definition of the media type
"application/soap+xml" talks about the serialization of the SOAP message
infoset and not any filtered or transformed version of that infoset, I
don't see how DTD can ever show up using that media type.

It may be possible to define other media types that provide such
filtering and/or transformation but that is outside our domain and would
require explicit definition of such filters and/or transformations which
I think is above and beyond what infoset provides.

Henrik

Received on Thursday, 5 December 2002 14:51:41 UTC