RE: AFTF requirements list with comments, pre-2003/01/28 telcon

> 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