Usage Scenarios review

 Hi all, 8-)
 I was tasked by the WG to review the Usage Scenarios document 
[1], particularly regarding implementability in SOAP 1.2.

 Shortly, I think all the description are OK in SOAP 1.2
(assuming SOAP with Attachments is updated with respect to
referencing attachments).

 Here's the listing of what I found (excluding what Dietmar
already pointed out in [2]; editorial comments listed below):

 - 2.3.2, first paragraph, last sentence: "In either case, the 
SOAP Sender is informed of the status (successful or otherwise) 
of the request message delivery."
 I don't think this is true when using a oneway transport like 
email (the second approach in this scenario).

 - In S4, I don't think it is necessary to describe using oneway 
transports to do request/response, it's already covered in S3 and 
possibly DS17.

 - In S5, I think it is necessary to change the StatusResponse 
header's meaning because it cannot conceivably contain a 
"UNDELIVERED" or "LOST" message status, can it? I suggest to 
remove the status and place the importance on TimeStamp, for 
example.

 - in 2.6.2, the example SOAP message contains the encrypted 
key - what is the key this key was encrypted with? I don't think 
the encrypted key should appear in the message at all.

 - S7 I believe a node that translates unicast message to 
multicast and does significant processing of the results should 
count as an intermediary. I suggest we rather give a "third party 
authorization intermediary" example:
 <envelope>
   <header>
     <clientCredentials role="auth.intermed." mU="true">
       ...
     </clientCredentials>
     <route role="next" mU="true">
       the path to the real target
     </route>
   </header>
   <body>
     ...
   </body>
 </envelope>
 And send this envelope to the intermediary. It obeys the routing 
header and replaces the clientCredentials (after verification) 
with something like
  <clientAuthorized>
    <sig>auth. imed. dig. sig.</sig>
  </clientAuthorized>

 - S10 should be coordinated with S6, like S6 encrypts, S10 signs.
Therefore I'd rename S10 to "Message header and payload dig.
signature".

 - 2.12.1 first paragraph after figure 14:
 "Support for non-XML data *is expected to be* described elsewhere".
 SOAP with Attachments doesn't work with SOAP 1.2 as-is because of
encoding changes. It can be updated easily, though.

 - S21: I don't think the scenario should stream binary data in
one XML (SOAP) envelope. I think S21 example (and affected
portions of the text) should be changed to chunks of XML data so
that putting it into an XML envelope is understandable. Otherwise
I think the scenario doesn't make sense, really.

 - Figure 17: I think the figure might be made more complete
(showing the whole of the scenario S23): in the left half, make
the arrows point in both directions, move the oval "event
subscription service" in between the first two boxes. Between the
two halves there could be an oval "notification on an event",
making the right half of the figure describe the notification
messages.

 - 2.16.2 first XML example - shouldn't there be a role attribute
on the CacheControl header?

 - 2.17.2: AFAIK the routing extension specification wasn't
updated for SOAP 1.2. I'd reword the section to say that the
scenario would be handled along the lines of this extension.

 - S809 should be collapsed entirely into DS24.

 
 

 Editorial comments:

 - the scenarios might need reordering in the text so that they 
appear in more logical order (like S23 after S20 after DS17).

 - S5 last XML snippet, the </n:statusresponse> should have 
capitalized S and R.

 - 2.6.1 "encryption method" rather than methodology, I think. 

 - 2.8.1 bullet 5: The buyer provides payment, the seller issue*s*
a receipt.

 - 2.8.1 after the numbered bullets: 
      ...are related *to* an instance of the TPA...
      ...message is valid within the scope of the TP*A*.

 - 2.9.1 instead of "a routing header may be appended..." I'd just
say "additional header may be appended...".

 - 2.11.2 second paragraph after figure 13: "...This forms *a*
part of the SOAP request message..."

 - 2.12.1 first paragraph after figure 14: "...impacts the
*binding of a message* to its underlying transport protocol."
What's a binding of a message?

 - figure 15: I think the first MIME part should be named "Root
MIME part". Also in the following paragraph, the "The first MIME
part" should be "The root MIME part".

 - 2.14.1 second paragraph: "Support for SOAP data models might
still..." should IMHO be "Support for *various* data models might
still...". 

 - 2.15.2 first paragraph after figure 17: "Figure XX" to "Figure
17".

 - 2.15.2 first two XML examples:
xmlns:s="http://example.org/2001/06/>subscribe" should remove the
pointy bracket.

 - 2.16.1 fourth paragraph: remove the leading pointy bracket.

 - 2.16.2 last paragraph, last sentence needs some attention, I
think. 8-)

 - 2.20 and further subsections of section 2 should be renumbered
to follow 2.18.

 - 2.21.2 (old numbering), second paragraph: "...may also requires
extensions..." remove the 's'.

 - 2.21.2 second paragraph last sentence needs closing
parenthesis. It's also unclear to me what this sentence means.



 Enjoy,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/

[1] http://www.w3.org/TR/2001/WD-xmlp-scenarios-20011217/
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0038.html

Received on Tuesday, 12 March 2002 00:37:17 UTC