AFTF requirements, pre-2003/02/11 WG telcon

AFTFers,

This version of the requirements reflects discussion up to the
2003/02/11 XMLP WG telcons.

Our current scorecard is:
  23 requirements agreed (R8, R9, R15, R24, R17, R1,
         R2, R3, R4, R5, R13, R26, R18, R27, R29, R21,
         R31, R22, R30, R6, R7, R11, R12)
  1 requirement that needs clarification (DR28)

R6, R11 and R26 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.

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.

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.

DR28. The specification may provide manifest functionality.

<davidO href="http://lists.w3.org/Archives/Public/xml-dist-app/2003Feb/0057.html">
An example of a manifest would be something like
<part ref="part1">
<part ref="part2">

The typical manifest functionality, where the list of parts in the package
are known ahead of time, or generated afterwards.  I'm not yet sure whether
I think that the type and length also should be in the manifest.

As for whether they would be in a soap envelope or not, I would say that "it
depends".  I think we need some more scenarios to figure out where the
possible places the manifest should ... manifest itself.  I tend to think
that it should be outside the soap envelope, so that there is a clean
separation between the soap and attachment functionality.
</davidO>


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.

Received on Tuesday, 11 February 2003 10:09:46 UTC