Comments inline.
My comments after reviewing of section 2.6.6:
I
thought we also agreed to group all new error together, so I propose to move
lines 907-935 (line numbers when changes not shown) to line 972. This way the
reporting options are described first, followed by the possible errors. This is
the as in the Core spec.
OK to move them, but note that all the new errors are also grouped
together in the new appendix G.
Rereading the paragraph on the new RoutingFailure error
(L920-935) I can’t see if any requirement is imposed on intermediary. On
L921 the generation of this error is made optional by the “MAY”, where on L922
support is required through the “MUST”. This difference will only make
sense when support [for this specific error] is something different then the
ability to generate and report this error. I don’t see such a difference, so I
would say that support is required and that reporting to the sender is
recommended, making it not required but also not completely optional.
OK.
Lines 928-935 state that the
generation of the RoutingFailure error should be done at the moment the message
is received. As implied by the text this allows for synchronous reporting of the
error, which is usefull when the other MSH uses pulling to receive messages. But
when messaging only occurs asynchronously there is no need to immediately apply
the routing rules and generate the error. Therefore I think the paragraph should
only state that it is required to apply the routing rules immediately after
receiving the message when synchronous reporting is used.
OK
The text on the error for
message expiration looks ambiguous because it is first stated that it is
possible that message expire and that this might be detected by the
intermediary. On line 1003 however it is stated that an intermediary should
discard a message when it detects a message is expired [according to the
wsr:ExpiryTime]. I would propose to make detection of message expiration and
generation of the error optional and only define the error that must be used
when message expiration is being checked by an intermediary.
The intention was to separate (i) any handling,
detection of expiration from (ii) the way that is done and based on which
header. A profile or implementation might define or support
other ways to express time to live / expiration than WS-Reliability, e.g. using
a new ebMS property to express business time to live, or information in the XML
business document payloads.
So the statement on (i) is that the intermediary MAY
detect expired messages.
The statement on (ii) is a particular comment on
WS-Reliability. To make this clear, we could change
"In particular, if the value of wsr:Request/wsr:ExpiryTime expresses that
the message has expired, as specified by WS-Reliability, the intermediary SHOULD
discard "
to
"In particular, if the intermediary
understands WS-Reliability headers, and if the value of wsr:Request/wsr:ExpiryTime
expresses that the message has expired, as specified by
WS-Reliability,
the intermediary SHOULD discard "
Furthermore I would require that when message
expiration is checked the error must be generated and that I can be reporting
using all described reporting options.
My impression is that the common approach to handling
expired messages is to just silently ignore them rather than generate an error.
That's why it's a MAY for generation too.
Two minor comments:
On (current, no
changes shown) line 906 add “in a multi-hop context ” after “... reporting ” and
on line 908 add “ by an intermediary” after “...
supported".
--
Sander
On 06/12/2009 15:30, "Pim Eijk, van
der" <
pvde@sonnenglanz.net>
wrote:
- Updated 2.6.6, latest discussions in TC.
-
2.6.6., remarks on expiration from
http://lists.oasis-open.org/archives/ebxml-msg/200910/msg00037.html
incorporated.
-
New subsection 3.4 in section 3.
- Some improvements for InOrder delivery
in section 3.
-- Mr. Pim van der Eijk
The document
revision named OASIS ebXML Messaging Services Version 3.0:
Part 2, Advanced
Features (v46) (ebMS3-part2-V46.odt) has been submitted by
Mr. Pim van der
Eijk to the OASIS ebXML Messaging Services TC document
repository.
This document is revision #16 of ebMS3-part2-V32-JD.odt.
Document
Description:
V46 of part 2.
- Updated 2.6.6, latest discussions
in TC.
- 2.6.6., remarks on expiration from
http://lists.oasis-open.org/archives/ebxml-msg/200910/msg00037.html
incorporated.
-
New subsection 3.4 in section 3.
- Some improvements for InOrder delivery
in section 3.
View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=35452
Download
Document:
http://www.oasis-open.org/committees/download.php/35452/ebMS3-part2-V46.odt
Revision:
This
document is revision #16 of ebMS3-part2-V32-JD.odt. The
document
details page referenced above will show the complete revision
history.
PLEASE NOTE: If the above links do not work for you,
your email application
may be breaking the link into two pieces. You
may be able to copy and paste
the entire link address into the address
field of your web browser.
-OASIS Open
Administration