Re: Comments from a Read-Through of Part 1

I'm not sure that I like the idea of this section being
an appendix. To me, this downplays its importance.
Just because there are no testable assertions, doesn't
make it any less important IMO.

If you want to mark it as non-normative, that might be
fine, but leave it where it is.

Cheers,

Chris

Marc Hadley wrote:

> Noah Mendelsohn/Cambridge/IBM wrote:
> 
>>
>> ** The second paragraph of section 1.4 "Robustness Principle" suggests 
>> that
>> our specification in all cases provides conservative values, but that the
>> robustness principle suggests that some unspecified broader set of values
>> should also be accepted.  While I like the robustness principle, I am
>> concerned about this formulation.  I think that in all cases we should
>> specify precisely what must be sent and what must be accepted.  In doing
>> so, we will often obey the robustness principle, and will indeed specify
>> that a receiver MUST accept values that a legal sender SHOULD NOT 
>> send.  I
>> do not think we should ever be vague about what a conforming receiver
>> should except.  Specifically, I would propose the following as a
>> replacement for the second paragraph: "The robustness principle is 
>> applied
>> for several purposes within this recommendation.  For example, section
>> 5.2.2 provides that senders SHOULD NOT send but receiver's MUST accept
>> certain values of the role attribute."
>>
> 
> Done, but text from the original paragraph describing the equivalence of 
> lexical forms of attribute values (e.g. "1" equivalent to "true" for 
> boolean) is retained for now in a separate paragraph added to section 1.2.
> 
> 
>> ** Section 1.2 second paragraph:  now says:  "all information items 
>> defined
>> by this specification are identified using XML namespace names".  That's
>> not true.  For example, the faultcode element is unqualified.  We should
>> either consistently qualify everything, or else change this statement in
>> section 1.2.
>>
> 
> Done, as a quick fix i have changed to "Some of the information 
> items...". I believe we discussed qualifying all elements a while ago 
> and decided against ?
> 
> 
>> ** Section 2.8, first paragraph: the reference at the end of the 
>> paragraph
>> is wrong.  It should be a reference to the section on extensibility, 
>> not to
>> the section on processing SOAP messages. In general, I think the wording
>> and presentation of this section could use a bit of cleanup.
>>
> 
> Done.
> 
> 
>> ** Section 5, first paragraph: the reference at the end of the first
>> paragraph is to the section in which the paragraph appears.
>>
> 
> Done.
> 
> 
>> ** Section 5: the last paragraph suggests that within any element defined
>> by this specification, whitespace character children are 
>> insignificant.  Is
>> this true for all of our fault elements, for example?  What about
>> FaultString?  I'm not expert enough on infoset, but I would expect that
>> fault strings can have significant whitespace.
>>
> 
> Done for fault string and detail entry (not detail). Are there any other 
> elements we define where whitespace is significant ?
> 
> 
>> **Section 5: in general, is there any ambiguity as to whether namespace
>> declarations, xsi:type, and other such attributes may appear on SOAP
>> constructs?  (see also comment immediately below)
>>
> Not done, see next item.
> 
>> ** Section 5.1: in the description of the envelope attribute information
>> item, we say "zero or more namespace qualified attribute information
>> items".  This vaguely suggests that user-defined qualified attributes may
>> be supplied in addition to those from our specification.  If the 
>> schema for
>> SOAP is normative (I don't remember whether it is) that might settle the
>> question, but in any case I think the wording could be more clear.  
>> Similar
>> comments would apply to the definitions of many other elements in chapter
>> 5.
>>
> Not done. The schema says the same thing as the text - do we want to 
> change ?
> 
>> ** Section 5.2.2: and/or section 2.3: do we state anywhere what the
>> comparison rules are for URI's used as role attributes?  Keep in mind 
>> that
>> in general on the web, such comparison rules are determined by the URI
>> scheme.  In the case of HTTP, case is not significant.  I think we 
>> want to
>> be clear that, as with XML namespaces, what we have in mind is straight
>> string comparison.  There's no way we want a SOAP processor to have to 
>> know
>> all the rules for a wide variety of schemes.  ...closely related to the
>> following proposal on section 6.0:
>>
> Not done, see next item.
> 
>> ** Section 6.0:  This section provides general information on the use of
>> URI's in SOAP, and specifically says:  "SOAP does not define any
>> equivalence rules for URIs in general as these are defined by the
>> individual URI schemes and by RFC 2396 [6]. However, because of
>> inconsistencies with respect to URI equivalence rules in many current URI
>> parsers, it is RECOMMENDED that SOAP senders do NOT rely on any special
>> equivalence rules in SOAP receivers in order to determine equivalence
>> between URI values used in a SOAP message."  In the case of role name
>> URI's, I think this is much too vague to guarantee interoperability.  For
>> example, it implies that an http URI used in a role attribute might come
>> back uppercased in a faultRole report, or that a role name of http://abc
>> might match http://aBc.   I suggest the following replacement for the
>> paragraph in question:  "SOAP does not in general define any equivalence
>> rules for URIs, except when used as the value for attributes defined in
>> this recommendation.   Where this recommendation calls for comparison 
>> with
>> attribute values of type anyURI  (e.g. when determining whether a node 
>> acts
>> in a role), equality is defined as identity of the sequence of character
>> information items comprising the attribute value.  Similarly, when a 
>> URI is
>> to be copied from one message to another (e.g. when a faultRole is
>> reported), an exact copy of the the characters MUST be supplied."
>>
> Not done, sounds OK to me - Henrik I think you wrote that section ?
> 
>> **Section 5.2.3, last paragraph: Current version: "If relaying the 
>> message,
>> a SOAP intermediary MAY substitute a non-canonical value with the 
>> canonical
>> value "true" and MAY omit the SOAP mustUnderstand attribute information
>> item if the value is "false" or "0"."   Proposed replacement: "If 
>> relaying
>> the message, a SOAP intermediary MAY substitute "true" for the value "1",
>> or "false" for "0".  The SOAP mustUnderstand attribute information 
>> item may
>> be omitted if its value would have been "false" or "0"."  The original
>> seemed to suggest that a non-canonical value for false (i.e. "0") 
>> could be
>> replaced by the canonical value "true".
>>
> Done.
> 
>> **Section 7.0 (Security Considerations): I strongly feel that this 
>> section
>> should be nonnormative and should be moved to an appendix.  It is 
>> strictly
>> advisory, and has essentially no testable assertions.  The possible
>> exception is section 7.3.1 which is on the use of ports.  If we want to
>> keep that in the main portion of the text, I suggest we move it to the
>> binding framework.  I also suggest that a bit more editing be done on
>> section 7, as the concepts are subtle and it's not always clear what's
>> really intended.
>>
> Not done, I support the suggestion to move it to a non-normative 
> appendix - any argument against ?
> 
> Regards,
> Marc.
> 
>

Received on Friday, 5 April 2002 09:56:59 UTC