Re: AFTF requirements list with comments, post-2003/01/28 telcon

On Thursday, Jan 30, 2003, at 13:58 US/Eastern, Mark Jones wrote:
>
> DR23.  <placeholder for compression requirement -- Marc H.>
>
I've slightly lost context on this one, but something along the lines  
of:

"The specification must be sufficiently flexible/extensible to allow  
for and describe transformations (encoding/compression/encryption/...)  
of parts."

I was thinking along the lines of HTTP where you have a media type plus  
a transfer encoding. The same thing might be useful in the package:  
this part is text/plain but is compressed using ... or this part is  
text/plain but is encrypted using ...

Regards,
Marc.

>
> Reference to Parts
> ------------------
>
> DR6. The specification must permit parts to be identified by URIs.
>
> <chris  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0025.html">
> Hmmm... I think that the specification should require that parts be
> identified by URI, but that they may be identified using other means
> as well. Of course, they could be identified by relative URI, not just
> absolute URI.
> </chris>
>
> <noah  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0037.html">
> +1 except for the references to relative URI.  I think we want:  The
> specification must provide that each part be identified by an (at least
> one) absolute URI.
>
> I think issues of relative should be above our level.  If some system
> (e.g. SOAP itself) wants to provide base URI and resolve relatives to
> absolute, that's fine, but we don't worry about that I think.  I would  
> not
> want a part to be known at the deepest level as "../p".
> </noah>
>
> <markJ  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0028.html">
> We can consider your wording instead.
> </markJ>
>
>
> DR7. The URI identification scheme must be robust under the addition
>      and deletion of parts -- i.e., it must not require that URIs to
>      other parts be altered, it must be relatively easy to avoid URI
>      conflicts, etc.
>
> DR11. (a) The specification should permit an initial human readable
>           part.
>       (b) The specification should not specify a particular ordering
>           of parts.
>       [still noodling on which version to prefer]
>
> <chris  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0025.html">
> Not sure I follow this...
> </chris>
>
> <markJ  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0028.html">
> There was some sentiment for flexibility in part ordering -- for
> example, having a text part preceeding even the SOAP message.
> </markJ>
>
> <noah  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0037.html">
> Right.  I also think the notion of "initial" is fuzzy.  Is it within  
> the
> first 100 bytes?  Is it no binary data between the start of message and
> this initial part (so you can use text tools to get that far).  Does it
> preclude interleaving?  I think this is too specific and we should drop
> it.
> </noah>
>
>
> DR12. The SOAP message part should be readily locatable/identifiable.
>
> <chris  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0025.html">
> Should it not be the case that ALL parts be identified, identifiable?
> What would make the SOAP part unique in this regard?
> </chris>
>
> <markJ  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0028.html">
> We wanted to make sure if there were multiple SOAP message
> parts that we could identify which one was the primary part and which
> were attachments.  This may be an issue if order were arbitrary, for
> example.
> </markJ>
>
> <noah  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0037.html">
> +1 but reword as"
>
> DR12. The primary (SOAP) message part should be readily
> locatable/identifiable.
>
> I think this correctly layers the packaging abstraction (part) from its
> use by SOAP.
> </noah>
>
>
> DR16. The part identifier scheme to be determined by sending
>       application.
>
> <chris  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0025.html">
> "scheme" seems to imply "URI", but my guess is that it does not.
> Again, I would strongly recommend that parts be identified by URI
> (relative or absolute).
> </chris>
>
> <markJ  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0028.html">
> URI is what I have in mind.
> </markJ>
>
> <noah  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0037.html">
> No.  I think that URI schemes should be used according to their
> definition.  This should not be a round-about way of enabling the  
> caching
> scenario (if that's what's intended.)  Cachcing can be enabled with a  
> SOAP
> feature (mapping an HTTP: URI to a CID:, for example).  The part in the
> message is unlikely to be correcly id'd directly with an HTTP URI  
> (unless
> we're doing lazy pull through an http network.)
> </noah>
>
> ________________________________________________________________
>
> 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  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0037.html">
> I'm confused too.
> </noah>
>
>
> 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  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0037.html">
> 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>
>
> <barton>
> Sanjiva, the key words here are "by receivers".  The serialization
> mechanism can have serious impacts on resource constrained or
> heavily loaded receivers.  Emitting a SOAP message in an
> HTTP-style MIME-like format without content-length headers leaves
> the receiver with no  recourse but multiple buffering layers and  
> repeated
> dynamic memory allocations as more content arrives.  For resource
> constrained receivers, the result is late and annoying buffer overflow;
> for heavily loaded receivers, the result is poor performance.
>
> This is, unfortunately not apple-pie since typically a  
> receiver-friendly
> protocol requires resources to be spent on the sender, eg to count
> the bytes as the package is assembled.  The specification will
> shift real costs.
>
> Hope this helps clarify this issue.
> </barton>
>
>
> 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  
> href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Jan/ 
> 0037.html">
> +1
> </noah>
>
>
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Thursday, 30 January 2003 14:47:26 UTC