OASIS ebXML Messaging Services TC

  • 1.  Groups - OASIS ebXML Messaging Services Version 3.0: Part 2, Advanced Features (v46) (ebMS3-part2-V46.odt) uploaded

    Posted 12-06-2009 14:31
    - 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
    


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

    Posted 12-09-2009 08:17
    
    
    
    
    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.

    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.

    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.

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

    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



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

    Posted 12-09-2009 12:16
    
    
    
    
    
     
    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