- From: Mark Jones <jones@research.att.com>
- Date: Fri, 7 Feb 2003 14:41:43 -0500 (EST)
- To: xml-dist-app@w3.org
AFTFers, This version of the requirements reflects discussion in the Friday, 2003/02/07 AFTF meeting. Our current scorecard is: 22 requirements agreed (R8, R9, R15, R24, R17, R1, R2, R3, R4, R5, R13, R30, R21, R31, R22, R18, R27, R29, R7, R6, R11, R26) 1 requirement that needs clarification (DR28) R6, R11 and R26 were the most problematic of the newly discussed requirements and have important philosophical issues associated with them. --mark Mark A. Jones AT&T Labs -- Strategic Standards Division Shannon Laboratory Room 2A02 180 Park Ave. Florham Park, NJ 07932-0971 email: jones@research.att.com phone: (973) 360-8326 fax: (973) 236-6453 ________________________________________________________________ Concrete Attachment Feature Requirements ---------------------------------------- The terminology used in this document is intended to be consistent with that found in the SOAP 1.2 Abstract Feature specification [http://www.w3.org/TR/2002/WD-soap12-af-20020814/]. Considerations -------------- * If existing packaging schemes (e.g., Multipart-MIME, DIME, ZIP, tar, jar, etc.) meet the requirements, or represent sensible tradeoffs, then the specification SHOULD use such existing schemes. * The specification should, where reasonably practical, be designed to facilitate message construction, parsing, debugging, tracing, implementation optimizations and other diagnostic activities. General Requirements -------------------- R8. The specification must describe its relationship to the properties defined in Table 1 (att:SOAPMessage and att:SecondaryPartBag) in the SOAP 1.2 Attachment Feature specification. R9. The specification must describe its points of extensibility. R15. The specification should be conveniently describable by languages such as WSDL. [WSDL should have enough extensibility to handle reasonable new attachment specifications include ours. Our spec should be reasonably describable by languages such as WSDL.] R24. The specification should include sample changes to WSDL 1.2 and/or extensions to WSDL. [Should this be decided by the WSCG?] R17. The specification must work with the SOAP 1.2 HTTP binding and shouldn't unnecessarily preclude working with other bindings. Representation -------------- R1. The specification must define a means to carry multiple data parts. R2. The specification must define a means for parts to carry arbitrary data, including non-XML data (e.g., binary data and XML fragments). R3: The specification should support efficient implementation of: a) parsing the physical representation to separate and identify its constituent parts. b) programming systems which efficiently resolve a URI to retrieve the data (and metadata) comprising the corresponding part. R4. The specification should use a reasonably space-efficient representation. R5. The representation should efficiently support the addition and deletion of parts by intermediaries. R13. The specification must provide support for arbitrarily large parts. R18. The specification must define a mapping between the attachment representation and a standalone SOAP message. For example, this may aid down-level receivers that do not understand this specification. R27. The specification should support securing of messages and message parts, such as use of encryption and signatures, in a simple manner. If practical, WS-Security should be supported. R29. [This requirement engendered a lot of discussion and has some significant ramifications for the Abstract Attachment Specification and for the basic conception of the SOAP message infoset.] (a) A message with all its parts, however separated physically, must be representable as a single infoset. (b) A message with all its parts, however separated physically, must be describable as a single XML element in an XML schema. Metadata -------- R21. The specification should provide convenient means for extending the metadata carried with a message. R31. The specification should provide convenient means for extending the metadata associated with individual parts. R22. The specification should provide a means by which any or all parts MAY be labeled with associated MIME types. (I.e. applications sending a message are not obligated to label parts with MIME types, but the specification must provide for carrying the MIME type if provided.) R30. The specification must provide an optional facility for specifying part size in advance. Reference to Parts ------------------ R6. Each part must be named by an absolute URI. The normal mechanisms of URI references may be employed to refer either to parts or to fragments. This requirement does not resolve another important issue which involves two competing views of the semantics of these URIs. One model is that any URI scheme can be used to name the parts. For example, the use of an http scheme would imply web caching semantics when resolving a URI reference. An alternative model is that there should be a chosen attachment URI scheme (e.g. the CID scheme in SwA). One could still implement a web caching semantics but would do so through the use of SOAP headers which would specify the http-to-CID mapping and interact with the URI resolver. R7. 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. R11. The specification should not specify a particular physical ordering of parts. In particular, this requirement was motivated by a use case in which the primary (SOAP) part was not required to be the first part. Physical order is significant, and there are cases in which control over physical order is important (for example, see R26). The issue here is whether the specification should be as rigid as SwA in insisting, for example, that the primary SOAP part be the first part. R12. The primary (SOAP) message part should be readily locatable/identifiable. R26. The specification should support streaming of parts, i.e. chunked encoding. We recognize use cases in which streaming, interleaving, chunking, etc. are important. Assuming that physical part order is significant and controllable, various packaging mechanisms would permit application-level solutions. The WG needs to decide whether to provide a more universal solution; if so, we need to collect enough use cases to properly design such a scheme. DR28. The specification may provide manifest functionality. David Orchard: Could you give us a concrete example of 'manifest' and explain why it would or wouldn't go in the SOAP envelope?
Received on Friday, 7 February 2003 14:42:36 UTC