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

["Pim van der Eijk" <pvde@sonnenglanz.net>]

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:sander@fieten-it.com]
Sent: 09 December 2009 09:16
To: ebxml-msg@lists.oasis-open.org
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" <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