- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Thu, 30 Jan 2003 14:47:53 -0500
- To: jones@research.att.com
- Cc: xml-dist-app@w3.org
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