Re: XMLP Last Call

insertedrespectappropriatebetweenappropriatesubstantiveMy comments on the 
SOAP last call documents follow. These don't reflect an official position 
of the xenc and xmldsig WGs (I don't think such a formal comment is 
needed), just my thoughts coming from that perspective. Most of the 
comments are editorial, my only  comment is my first one.

# SOAP Version 1.2 Usage Scenarios
# W3C Working Draft 26 June 2002
#    This version:
#           http://www.w3.org/TR/2002/WD-xmlp-scenarios-20020626
# 2.6 S6 Request with encrypted payload
# 
# 2.6.1 Scenario Definition
# 
#    A sender wishes to exchange data with a receiver and has agreed to
#    encrypt the payload. The sending and receiving applications agree on
#    the encryption methodology. Data is encrypted by the originating
#    application and sent to the receiver via SOAP. The data reaches the
#    receiving application untouched, and may then be decrypted in the
#    agreed-upon manner.

The *most* problematic issue for Signatures and Encryption are those related 
to detaching and inserting XML in one document from another. Simply, XML 
was not designed to do this well, and in many circumstances its not 
possible to do it well. Consequently, I believe that applications that do 
this need to be very clear about the methods of removal/insertion and SOAP 
seems an obvious example of this. I'd think the WG should consider either 
defining a mechanism of attachment/detachment (and the related Infoset 
clean up) or contrain/warn applications as xmldsig [1] and xenc [2] have 
done about the use of xmlns="", and xml:foo attributes, and using qualified 
names in attribute values -- or at least quickly repeat/reference those 
arnings.

[1] http://www.w3.org/Signature/Drafts/xml-exc-c14n.html#sec-Considerations
5. Security Considerations

   This specification is used to serialize an XPath node-set under
   certain assumptions given in [XML-C14N] and this specification. Three
   such examples include:
    1. implementations of [XML-C14N] and this specification do not render
       an XML declaration;
    2. implementations of this specification only render attributes from
       the "XML" namespace (e.g., xml:lang, xml:space, and xml:base) when
       they are in the subset being serialized;
    3. implementations of this specification do not consider the
       appearance of a namespace prefix within an attribute value to be
       visibly utilized.

   While such choices are consistent with other XML specifications and
   satisfy the Working Group's application requirements it is important
   that an XML application carefully construct its transforms such that
   the result is meaningful and unambiguous in its application context.
   In addition to this section, the Limitations of this specification,
   the Resolutions of [XML-C14N], and the Security Considerations of
   [XML-DSig] should be carefully attended to.

  5.1 Target Context

   The requirement of this specification is to satisfy applications that
   "require a method which, to the extent practical, excludes ancestor
   context from a canonicalized subdocument." Given a fragment being
   removed from its source instance, this specification satisfies this
   requirement by excluding from the fragment any context from its
   ancestors that is not utilized. Consequently, a signature [XML-DSig]
   over that fragment will remain valid in its source context, removed
   from the source context, and even in a new target context. However,
   this specification does not insulate the fragment against confused
   interpretation in a target context.

   For example, if the <Foo/> element is signed in its source instance of
   <Bar/><Foo/></Bar> and then removed and placed in the target instance
   <Baz xmlns="http://example.org/bar"/><Foo/></Baz>, the signature
   should still be valid, but won't be if <Foo/> is interprated as
   belonging to the http://example.org/bar namespace: this is dependent
   on how nodes are processed.

   This specification does not define mechanisms of removing, inserting,
   and "fixing up" a node-set. (For an example of this sort of
   specification, see the processing required of Creating the Result
   Infoset (section 4.5) when an [XInclude] is performed.) Instead,
   applications must carefully specify the XML (i.e., source, fragment,
   and target) or define the node-set processing (i.e., removal,
   replacement, and insertion) with respect to default namespace
   declarations (e.g., xmlns="") and XML attributes (e.g., xml:lang,
   xml:space, and xml:base).

[2] 
http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/Overview#sec-Serializing-XML


# SOAP Version 1.2 Part 0: Primer
# W3C Working Draft 26 June 2002
#    This version:
#           http://www.w3.org/TR/2002/WD-soap12-part0-20020626
#    Following completion of Last Call, the XML Protocol Working Group has
#    agreed to advance the specification according to four exit criteria:
#     1. Sufficient reports of implementation experience have been gathered
#        to demonstrate that SOAP processors based on the specification are
#        implementable and have compatible behavior.


What does this mean in the context of the primer and scenarios? Will you 
want to see evidence of all the scenarios having been accomplished before 
you advance the specifications?

#     2. An implementation report shows that there are at least two
#        different and interoperable implementations of every mandatory and
#        optional feature.

My comment is more  to Part 1, then this primer, but I also recommend a 
requirement of one COMPLETE implementation of all mandatory features: 
"Given different implementations, their variance in the 20% each fails to 
do well causes 80% of the users' headaches."

#    Therefore, when a RPC definition is such that all the parts of its
#    method signature can be described as resource-identifying and hence

Please define "method signature", this will be useful and also make it clear 
you are not speaking of a digital signature.

#    Example 5b
#        <rpc:result>m:status</rpc:result>
#        <m:status>confirmed</m:status>

This is a very odd sort of construct. I know it's just an example, but is 
this sort of thing expected to be the norm, I would expect:
  <rpc:result><m:status>confirmed</m:status></rpc:result>

#   2.3 Fault scenarios
#    The SOAP Body element has another distinguished role in that it is the
#    place where such fault information is placed. The SOAP fault model
#    (see Part 1, section 5.4) requires that all SOAP-specific and
#    application-specific faults be reported using a single distinguished
#    element, Fault, carried within the Body element. The Fault
#    element contains two mandatory sub-elements, Code and
#    Reason, and (optionally) application-specific information in the
#    Detail sub-element within the Fault. Another optional
#    sub-element, Node, identifies via a URI the SOAP node which
#    generated the fault, its absence implying that it was the ultimate
#    recipient of the message which did so. There is another optional
#    sub-element, Role, which identifies the role that the node which
#    generated the fault was playing.

The various specifications repeatedly attempt to define the difference  the 
header and the body, which I appreciate, but I'm still a little confused. I 
understand that header information is of interest on the hop 
(intermediaries) but the body is for the end-to-end (destination). But if 
I'm putting error messages in the body, couldn't it be possible that the 
intermediaries would be interested in that as well?
 
#    Part 1 section 5.4 of the SOAP specifications describes the
#    structure of the fault message while the SOAP processing model defines

I was briefly confused by these "Part 1" section foo, I kept thinking, Part 
1 of what specification? I know it's stated in section 1, but perhaps on 
the first few instances in the text, you could include the full name.

#    Example 12b

In the Primer, an example has the "Example #" and a description below the 
example, Part 1 has the description at the top. These should be harmonized, 
I prefer it at the top.

# SOAP Version 1.2 Part 1: Messaging Framework
# W3C Working Draft 26 June 2002
#    This version:
#           http://www.w3.org/TR/2002/WD-soap12-part1-20020626
# 1.2.2 Robustness Principle
# 
#    In some cases, the use of XML technologies allows the flexibility for
#    expressing semantically equivalent statements in a variety of
#    different ways. In order to obtain robust and interoperable
#    implementations it is essential that SOAP implementations take into
#    account the Robustness Principle as expressed by RFC 1123 
#    and RFC 793 : "Be liberal in what you accept, and
#    conservative in what you send".

I know this can be a matter of debate, but I believe this principle has 
caused the majority of headaches of users of document formats: permitting 
innumerable cruddy instances which necessitate complex heuristic based 
parser/applications. While it is still  in some limited protocol scenarios, 
I'm generally cautious towards it, and oppose it with  to document 
syntaxes.

# 2.2 SOAP Roles and SOAP Nodes
#    This specification defines the following SOAP roles:
#      * "http://www.w3.org/2002/06/soap-envelope/role/next". Each SOAP
#        intermediary and the ultimate SOAP receiver MUST act in this role
#        and MAY additionally assume zero or more other SOAP roles.
#      * "http://www.w3.org/2002/06/soap-envelope/role/none". SOAP nodes
#        MUST NOT act in this role.
#      * "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver".
#        To establish itself as an ultimate SOAP receiver a SOAP node MUST
#        act in this role. SOAP intermediaries MUST NOT act in this role.

Where? If the intent is to define them here, it merely states if a SOAP node 
can act in the role, I really haven't found a good definition of these 
roles.

# 2.4 Understanding SOAP Headers
#    Mandatory SOAP header blocks are presumed to somehow modify the
#    semantics of other headers or body elements. 

This surprises me, I'd think I could have Mandatory SOAP headers that can 
co-exist, however on further thought this sounds like a good idea.

# 5. SOAP Message Construct
# 
#    The XML infoset of a SOAP message MUST NOT contain a document type
#    declaration information item.
# 
#    A SOAP message SHOULD NOT contain processing instruction information
#    items. A SOAP receiver MUST ignore processing instruction information
#    items in SOAP messages that it receives.

I recommend you also make (or reference) further constraints on xml:foo and 
other issues I mentioned if it's likely that the payload will be detached/ 
-- unless you define methods of changing the Infoset in these ways.

# 6. Use of URIs in SOAP
#
#    SOAP does not define a base URI but relies on the mechanisms defined
#    in XML Base  and RFC 2396  for establishing a base
#    URI against which relative URIs can be made absolute.

Again, use of base URIs across payload attach/detach boundaries should be 
constrained.


# SOAP Version 1.2 Part 2: Adjuncts
# W3C Working Draft 26 June 2002
#    This version:
#           http://www.w3.org/TR/2002/WD-soap12-part2-20020626
# 3.1 Rules for Encoding Graphs in XML

Would the RDF datamodel and serialization suffice in place of this?

Received on Friday, 12 July 2002 15:24:30 UTC