- From: John Ibbotson <john_ibbotson@uk.ibm.com>
- Date: Mon, 18 Mar 2002 14:07:17 +0000
- To: undisclosed-recipients:;
- To: Jacek Kopecky <jacek@systinet.com>, xml-dist-app@w3.org
Jack,
Comments below.
John
Emerging ebusiness Industry Architecture ,
XML Technology and Messaging,
IBM UK Ltd, Hursley Park,
Winchester, SO21 2JN
Tel: (work) +44 (0)1962 815188 (home) +44 (0)1722 781271
Fax: +44 (0)1962 816898
Notes Id: John Ibbotson/UK/IBM
email: john_ibbotson@uk.ibm.com
Jacek Kopecky
<jacek@systinet.c To: xml-dist-app@w3.org
om> cc: John Ibbotson/UK/IBM@IBMGB, David Fallside/Santa Teresa/IBM@IBMUS
Subject: Usage Scenarios review
03/10/2002 10:02
PM
Please respond to
Jacek Kopecky
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).
<jbi> All the scenario descriptions are what we decided during the
requirements gathering process so I don't plan to change them in
this document. Scenario S3 addresses a SOAP request/response mep
which is independent of the underlying transport binding. For email
this mep would have to be supported by an explicit response email
to the originator of the request.
</jbi>
- 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.
<jbi> Possibly agree. But in a few cases I have repeated things to
make particular points. In this case it is to emphasise that RPC
is not only synchronous request/response.
</jbi>
- 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.
<jbi> I don't see a reference to UNDELIVERED or LOST in the text.
If you are referring to the second bullet in the 2.5.1, then that
is the text we agreed during the requirements gathering process.
</jbi>
- 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.
<jbi> This was lifted from an XML DSIG example. If this is wrong,
how should it be changed ? </jbi>
- 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>
<jbi> The marketplace example is the one that was selected during
the requirements process and appears in the requirements document.
</jbi>
- S10 should be coordinated with S6, like S6 encrypts, S10 signs.
Therefore I'd rename S10 to "Message header and payload dig.
signature".
<jbi> Once again, the scenario titles are part of the requirements document
so I don't want to change them. I do need an example for this section.
can you help ? </jbi>
- 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.
<jbi> Changed </jbi>
- 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.
<jbi> The examples in the Usage Scenario document are only one way
of implementation. I'm sure that in many cases they may not be the best
but gives us a tick in the box that SOAP 1.2 supports them.
</jbi>
- 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?
<jbi> Yes </jbi>
- 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.
<jbi> Done </jbi>
- S809 should be collapsed entirely into DS24.
<jbi> Kept separate to preserve ordering from requirements document.
</jbi>
Editorial comments:
- the scenarios might need reordering in the text so that they
appear in more logical order (like S23 after S20 after DS17).
<jbi> Ordering matches requirements document.</jbi>
- S5 last XML snippet, the </n:statusresponse> should have
capitalized S and R.
<jbi> Done </jbi>
- 2.6.1 "encryption method" rather than methodology, I think.
<jbi> Done </jbi>
- 2.8.1 bullet 5: The buyer provides payment, the seller issue*s*
a receipt.
<jbi> Done </jbi>
- 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*.
<jbi> Done </jbi>
- 2.9.1 instead of "a routing header may be appended..." I'd just
say "additional header may be appended...".
<jbi> Part of scenario definition from requirements </jbi>
- 2.11.2 second paragraph after figure 13: "...This forms *a*
part of the SOAP request message..."
<jbi> Done </jbi>
- 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?
<jbi> Done </jbi>
- 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".
<jbi> Done </jbi>
- 2.14.1 second paragraph: "Support for SOAP data models might
still..." should IMHO be "Support for *various* data models might
still...".
<jbi> Done </jbi>
- 2.15.2 first paragraph after figure 17: "Figure XX" to "Figure
17".
<jbi> Done </jbi>
- 2.15.2 first two XML examples:
xmlns:s="http://example.org/2001/06/>subscribe" should remove the
pointy bracket.
<jbi> Done </jbi>
- 2.16.1 fourth paragraph: remove the leading pointy bracket.
<jbi> Done </jbi>
- 2.16.2 last paragraph, last sentence needs some attention, I
think. 8-)
<jbi> Done </jbi>
- 2.20 and further subsections of section 2 should be renumbered
to follow 2.18.
<jbi> Done </jbi>
- 2.21.2 (old numbering), second paragraph: "...may also requires
extensions..." remove the 's'.
<jbi> Done </jbi>
- 2.21.2 second paragraph last sentence needs closing
parenthesis. It's also unclear to me what this sentence means.
<jbi> Removed </jbi>
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 Monday, 18 March 2002 09:14:50 UTC