RE: [ebxml-msg] Groups - OASIS ebXML Messaging Services Version 3.0: Part 2, Advanced Features (v46) (ebMS3-part2-V46.odt) uploaded

Title: Re: [ebxml-msg] Groups - OASIS ebXML Messaging Services Version 3.0: Part 2, Advanced   Features (v46) (ebMS3-part2-V46.odt) uploaded

 

Comments inline.

 

 

  From: Sander 
Fieten [mailto:] 
Sent: 09 December 2009 
09:16
To: 
Subject: Re: 
[ebxml-msg] Groups - OASIS ebXML Messaging Services Version 3.0: Part 2, 
Advanced Features (v46) (ebMS3-part2-V46.odt) 
uploaded

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" <> 
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