- From: Jeffrey Schlimmer <jeffsch@windows.microsoft.com>
- Date: Fri, 31 Jan 2003 09:37:40 -0800
- To: <noah_mendelsohn@us.ibm.com>, <jones@research.att.com>
- Cc: <xml-dist-app@w3.org>, <sanjiva@us.ibm.com>
> New proposed requirements: > -------------------------- > > DR18. The specification must define a means to format messages for > down-level receivers that do not understand the specification. > > <sanjiva href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0034.html"> > How can any spec say something about those who don't understand the > spec? I'm confused. > </sanjiva> > > <barton href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0033.html"> > Maybe you can clarify this one Jeff...the way I read it, it sounds > impossible. > </barton> <noah> I'm confused too. </noah> <jeff> This is just a down-level requirement; we're defining a more efficient way to do something, and it is reasonable for us to describe the current, less-efficient way for up-level receivers to communicate with down-level receivers. If you're concerned that such a requirement may be difficult to satisify, I'll point out that one option would be to send in-lined, base64 content if the receiver doesn't understand the spec. </jeff> > DR19. The specification must enable efficient allocation of buffers by > receivers. > > <sanjiva href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0034.html"> > I'm again confused; while a statement like "this spec > must be implementable as efficiently as possible" is > reasonable (and motherhood-and-apple-pie IMO), speaking > specifically about buffer allocation seems rather > pointed. > </sanjiva> > > <barton href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0033.html"> > > This one motivates some of the other requirements but > it implies that the sender understand the receiver's > memory allocation capabilities. On one extreme the > requirement could amount to "give the content length of > attachments up front", but at the other extreme it > could require the interleaving of parts to achieve a > serialization optimal for receiver processing. > > > As an example of the latter, the UPNP Printing folks > worried about how an extremely long XHTML doc with many > inline images could be a printed with one page buffer. > While that may seem like an example far from the one > most SOAP folks consider, once you get to pipelined > processing of composed > > SOAP services the differences begin to fade. These are > cases you want to be able to handle and they are cases > that non-XML systems deal with. > > Of course the serialization of XHTML is well-defined. > Serialization for arbitrary receiver processing isn't. > That makes this requirement difficult to spell out > absent information on the receiver buffer capability. > Consequently one might go for a requirement that asks > the spec. to allow attachments to be placed in the > stream physically near their first point of XML > reference rather than getting into buffers. That would > pick up the critical use case without getting mired in > an open-ended problem. > </barton> <noah> I think we can say: "Attention should be given to likely implementation optimizations. I agree with Sanjiva, going much beyond that is too specific.) </noah> <jeff> I can live with this, but as John Barton points out, there is a specific efficiency concern associated with unbounded buffering required by the receiver. </jeff> > DR20. The specification must allow messages to be secured using the > mechanisms defined in WS-Security. > > <sanjiva href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/0034.html"> > WS-Security only applies to SOAP envelopes. This > requirement would hence have the effect of precluding > MIME/DIME style packaging .. > </sanjiva> <noah> +1 </noah> <jeff> It is not at all clear that using WS-Security precludes MIME or DIME style packaging. WS-Security applies to an Infoset, and MIME and DIME may (or may not) end up being a serialization of the Infoset. As David has pointed out, we must define how to secure messages; it would seem unnatural for us to not reference the emerging Web Services security technology. </jeff>
Received on Friday, 31 January 2003 12:38:20 UTC