new version of requirements following ARTF telcon of 2003-01-15

Here is another list of requirements following the ARTF (Attachment
Requirements Task Force) telcon held from 11am-noon EST on Jan. 15,
2003.  A couple of former draft requirements have been moved forward
to "Considerations" instead.  Those requirements marked "DR" have not
yet been discussed in detail by the task force; those requirements
marked "R" have achieved consensus within the task force.

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
----------------------------------------

Considerations

* The specification should not invent a packaging scheme.
* The specification should aid debugging with simple tools.


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 not unecessarily preclude convenient
      description by languages such as WSDL.

DR17. The specification must work with the SOAP 1.2 HTTP binding and
      with as many other bindings as possible.



Representation

DR1. The specification must define a means to carry multiple data parts.

DR2. The specification must define a means for parts to carry
     arbitrary data, including non-XML data (e.g., binary data and XML
     fragments).

DR3. The specification must admit a reasonably time-efficient means of
     identifying parts.

DR4. The specification must use a reasonably space-efficient
     representation.

DR5. The representation must efficiently support the addition and
     deletion of parts.

DR13. The specification must provide support for large parts.



Reference to Parts

DR6. The specification must permit parts to be identified by URIs.

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]

DR12. The SOAP message part should be readily locatable/indentifiable.

DR16. The part identifier scheme to be detremined by sending
      application.

Received on Wednesday, 15 January 2003 12:10:44 UTC