OASIS ebXML Messaging Services TC

  • 1.  Groups - ebXML Messaging TC weekly call added

    Posted 04-06-2010 13:36
      |   view attached

    Attachment(s)

    ics
    ical_26902.ics   658 B 1 version


  • 2.  Re: [ebxml-msg] Groups - ebXML Messaging TC weekly call added

    Posted 04-06-2010 16:31
    
    
    
    
    Yes, I’ve looked a bit more into restart when pulling.

    I’ve read the HTTP spec on the use of the Range request header. In section 14.35.2 where this header is specified it is only described for the GET method. In section 3.12 on Range units however it is stated that ranges can be used to request ranges of the response entity without mention of specific request methods. It however seems logical to use the GET method because you want ranges of the same resource for which you typically use a GET.  But I think that the semantics of the Range header could also be used with the POST method. The question then is what to post, an empty entity body ?
    And another aspect with regard to security is how to authenticate the pulling endpoint when XML security is used. This would mean that subsequent range requests should include an XML document. If HTTP security is used this would not be a problem.  

    When extending the ebMS protocol for Pulling to allow for partial pulling the PullRequest signal could be extended with a PartialPull element. Then an initial PullRequest to start a partial pull would look like:

    <eb:SignalMessage>
      <eb:MessageInfo>
        <eb:Timestamp>2006-07-25T12:19:05</eb:Timestamp>
        <eb:MessageId>UUID-1@initiator.example.com</eb:MessageId>">UUID-1@initiator.example.com</eb:MessageId>
     </eb:MessageInfo>
      <eb:PullRequest mpc="http://msh.example.com/mpc123">
       <eb:PartialPull/>
     </eb:PullRequest>
    </eb:SignalMessage>

    The Responding endpoint then replies with only the only the SOAP envelop which inlcudes the ebMS header. This will inlcude an <eb:UserMessage> element that contains the meta data on the payloads. For example:

    <eb:UserMessage
    mpc="http://msh.example.com/mpc123">
        <eb:MessageInfo>
            <eb:Timestamp>2006-07-25T12:19:06</eb:Timestamp>
            <eb:MessageId>UUID-2@responder.example.com</eb:MessageId>">UUID-2@responder.example.com</eb:MessageId>
        </eb:MessageInfo>
        ...
        <eb:PayloadInfo>
                <eb:PartInfo href="cid:foo@example.com"/">foo@example.com"/>
                <eb:PartInfo href=”cid:bar@example.com”/">bar@example.com”/>
        </eb:PayloadInfo>
    <eb:UserMessage>
        
    Now the initiating endpoint can pull parts of the payload using new PullRequests with the PartialPull element specifying what to pull. Such a request would look like:

    <eb:SignalMessage>
     <eb:MessageInfo>
        <eb:Timestamp>2006-07-25T12:19:08</eb:Timestamp>
        <eb:MessageId>UUID-3@initiator.example.com</eb:MessageId>
     </eb:MessageInfo>
      <eb:PullRequest mpc="http://msh.example.com/mpc123">
       <eb:PartialPull>
               <eb:RefToMessageId>UUID-2@responder.example.com</eb:RefToMessageId>
               <!-- Part element can be repeated for pulling parts of multiple payloads -->
                
    <eb:Part href=«reference to payload as included in eb:UserMessage/eb:PayloadInfo[@href]»
                            range=«As specified in RFC2616 (HTTP 1.1)»
              />
               </eb:Part>
      </eb:PartialPull>
     </eb:PullRequest>
    </eb:SignalMessage>

    Response to this request could be only the requested data, without any ebMS and/or SOAP envelop or a complete ebMS header (which could be a recurrence of the original header).
    Using ebMS message to pull parts security can be arrange like normal PullRequests. What needs to be configured in both scenario’s is how long the responding endpoint should retain the data. When the parts are sent within a SOAP envelop RM could be used to ensure successful transmission of the parts and data can be deleted when the part is successfully transmitted.

    The above is only a rough sketch of both options. I can work them out based on discussion tomorrow.

    Regards,
    Sander  

     

    On 06/04/2010 15:36, "ian.c.jones@bt.com" <ian.c.jones@bt.com> wrote:

    Team,

        all times usual.  Any more comments on restart or selective pulling??

    Ian

     -- Ian Jones


    ebXML Messaging TC weekly call has been added by Ian Jones

    Date:  Wednesday, 07 April 2010
    Time:  11:30am - 01:00pm PT

    Event Description:
    ebXML Messaging TC weekly call

    Tel: +1-218-486-8700
    Pass code 120905

    Agenda:
    1. Role
    2. Review of this weeks updates
     Restart (AS2)
     Pulling specific document
    3. AS4 - Updates
    4. A.O.B

    Minutes:


    View event details:
    http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/event.php?event_id=26902

    PLEASE NOTE:  If the above link does 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.




  • 3.  RE: [ebxml-msg] Groups - ebXML Messaging TC weekly call added

    Posted 04-07-2010 00:13
    
    
    
    
    
    Does the requestor (receiver) need to be selective on which MIME part is to be [partially] pulled?  That seems to give too much initiative / too many options to the receiving MSH, for such a low-level feature.
     
    Another approach is to have the "partial" PullRequest only specify a maxsize ("range") value, as a measure of what maxsize the chunks should be. The receiver then iteratively pulls on a particular message until all its parts have been obtained - and reassembles the full user message. The sender is deciding of which attachments need be split, and which msg part to send next. 
     
    We could also have this maxsize value to be part of a PMode configuration, and the pulling of *any* large message to be automatically handled using the range approach when and if needed. In that case, the PullRequest does not even need be different from a regular PullRequest. A new warning piggybacked on the partial response could indicate to the receiving MSH that the message is not complete yet.
     
    -jacques


    From: Sander Fieten [mailto:sander@fieten-it.com]
    Sent: Tuesday, April 06, 2010 9:30 AM
    To: ebxml-msg@lists.oasis-open.org
    Subject: Re: [ebxml-msg] Groups - ebXML Messaging TC weekly call added

    Yes, I’ve looked a bit more into restart when pulling.

    I’ve read the HTTP spec on the use of the Range request header. In section 14.35.2 where this header is specified it is only described for the GET method. In section 3.12 on Range units however it is stated that ranges can be used to request ranges of the response entity without mention of specific request methods. It however seems logical to use the GET method because you want ranges of the same resource for which you typically use a GET.  But I think that the semantics of the Range header could also be used with the POST method. The question then is what to post, an empty entity body ?
    And another aspect with regard to security is how to authenticate the pulling endpoint when XML security is used. This would mean that subsequent range requests should include an XML document. If HTTP security is used this would not be a problem.  

    When extending the ebMS protocol for Pulling to allow for partial pulling the PullRequest signal could be extended with a PartialPull element. Then an initial PullRequest to start a partial pull would look like:

    <eb:SignalMessage>
      <eb:MessageInfo>
        <eb:Timestamp>2006-07-25T12:19:05</eb:Timestamp>
        <eb:MessageId>UUID-1@initiator.example.com</eb:MessageId>">UUID-1@initiator.example.com</eb:MessageId>
     </eb:MessageInfo>
      <eb:PullRequest mpc="http://msh.example.com/mpc123">
       <eb:PartialPull/>
     </eb:PullRequest>
    </eb:SignalMessage>

    The Responding endpoint then replies with only the only the SOAP envelop which inlcudes the ebMS header. This will inlcude an <eb:UserMessage> element that contains the meta data on the payloads. For example:

    <eb:UserMessage
    mpc="http://msh.example.com/mpc123">
        <eb:MessageInfo>
            <eb:Timestamp>2006-07-25T12:19:06</eb:Timestamp>
            <eb:MessageId>UUID-2@responder.example.com</eb:MessageId>">UUID-2@responder.example.com</eb:MessageId>
        </eb:MessageInfo>
        ...
        <eb:PayloadInfo>
                <eb:PartInfo href="cid:foo@example.com"/">foo@example.com"/>
                <eb:PartInfo href=”cid:bar@example.com”/">bar@example.com”/>
        </eb:PayloadInfo>
    <eb:UserMessage>
        
    Now the initiating endpoint can pull parts of the payload using new PullRequests with the PartialPull element specifying what to pull. Such a request would look like:

    <eb:SignalMessage>
     <eb:MessageInfo>
        <eb:Timestamp>2006-07-25T12:19:08</eb:Timestamp>
        <eb:MessageId>UUID-3@initiator.example.com</eb:MessageId>
     </eb:MessageInfo>
      <eb:PullRequest mpc="http://msh.example.com/mpc123">
       <eb:PartialPull>
               <eb:RefToMessageId>UUID-2@responder.example.com</eb:RefToMessageId>
               <!-- Part element can be repeated for pulling parts of multiple payloads -->
                
    <eb:Part href=«reference to payload as included in eb:UserMessage/eb:PayloadInfo[@href]»
                            range=«As specified in RFC2616 (HTTP 1.1)»
              />
               </eb:Part>
      </eb:PartialPull>
     </eb:PullRequest>
    </eb:SignalMessage>

    Response to this request could be only the requested data, without any ebMS and/or SOAP envelop or a complete ebMS header (which could be a recurrence of the original header).
    Using ebMS message to pull parts security can be arrange like normal PullRequests. What needs to be configured in both scenario’s is how long the responding endpoint should retain the data. When the parts are sent within a SOAP envelop RM could be used to ensure successful transmission of the parts and data can be deleted when the part is successfully transmitted.

    The above is only a rough sketch of both options. I can work them out based on discussion tomorrow.

    Regards,
    Sander  

     

    On 06/04/2010 15:36, "ian.c.jones@bt.com" <ian.c.jones@bt.com> wrote:

    Team,

        all times usual.  Any more comments on restart or selective pulling??

    Ian

     -- Ian Jones


    ebXML Messaging TC weekly call has been added by Ian Jones

    Date:  Wednesday, 07 April 2010
    Time:  11:30am - 01:00pm PT

    Event Description:
    ebXML Messaging TC weekly call

    Tel: +1-218-486-8700
    Pass code 120905

    Agenda:
    1. Role
    2. Review of this weeks updates
     Restart (AS2)
     Pulling specific document
    3. AS4 - Updates
    4. A.O.B

    Minutes:


    View event details:
    http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/event.php?event_id=26902

    PLEASE NOTE:  If the above link does 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.




  • 4.  RE: [ebxml-msg] Groups - ebXML Messaging TC weekly call added

    Posted 04-07-2010 17:47
    
    
    
    
    
    
    
    
    
    
    
    
    

    On the first question posed about pull restart, Sander noted that no prohibition has been found in using “Range” to identify a desired range. What are we assuming the pull agent knows when it makes a pull request? Some kind of transmission problem might have occurred. Should we require that a HTTP status of 2XX has made it back? (If not, retry instead of restart might be the better approach…) Should restart presume that content-length was received as well for the HTTP response? Finally if we use a MPC and authentication, how do we identify the specific MPC queue item that was partially received? (Also how long are these items to be kept available. (Maybe the server side of the pull scenario does not have a reliable way of telling exactly whether the pulled entitity made it all the way back on the so-called “back channel”. (A digression: has anyone noticed that SAML uses the terms “back channel and “front channel” in ways that conflict with WS-splat specifications? Or since SAML was first, that WS-splat misused their technical term J)

    Anyway IMO we need to solve the above issues (and probably some more) before we have a generic pull restart solution (and I think that because we do not want other parties trying to pull items or parts of items off a MPC, we really will not have a generic HTTP  pull-restart proposal. That is, we have to make use of the MPC and identification methods supported in ebMS 3 pull mode (while adding some item identifier. Would a toplevel HTTP header like “Content-id” work? Any other and better candidates?)

    On the partial pull request, maybe we should solve the preceding problem about identifying the message (or the message parts), and then see whether that solution covers whatever is needed for partial pull. (I think this matches Jacques’s remark that “it need not be different from a regular PullRequest)


    From: Jacques R. Durand [mailto:JDurand@us.fujitsu.com]
    Sent: Tuesday, April 06, 2010 5:12 PM
    To: Sander Fieten; ebxml-msg@lists.oasis-open.org
    Subject: RE: [ebxml-msg] Groups - ebXML Messaging TC weekly call added

    Does the requestor (receiver) need to be selective on which MIME part is to be [partially] pulled?  That seems to give too much initiative / too many options to the receiving MSH, for such a low-level feature.

     

    Another approach is to have the "partial" PullRequest only specify a maxsize ("range") value, as a measure of what maxsize the chunks should be. The receiver then iteratively pulls on a particular message until all its parts have been obtained - and reassembles the full user message. The sender is deciding of which attachments need be split, and which msg part to send next. 

     

    We could also have this maxsize value to be part of a PMode configuration, and the pulling of *any* large message to be automatically handled using the range approach when and if needed. In that case, the PullRequest does not even need be different from a regular PullRequest. A new warning piggybacked on the partial response could indicate to the receiving MSH that the message is not complete yet.

     

    -jacques


    From: Sander Fieten [mailto:sander@fieten-it.com]
    Sent: Tuesday, April 06, 2010 9:30 AM
    To: ebxml-msg@lists.oasis-open.org
    Subject: Re: [ebxml-msg] Groups - ebXML Messaging TC weekly call added

    Yes, I’ve looked a bit more into restart when pulling.

    I’ve read the HTTP spec on the use of the Range request header. In section 14.35.2 where this header is specified it is only described for the GET method. In section 3.12 on Range units however it is stated that ranges can be used to request ranges of the response entity without mention of specific request methods. It however seems logical to use the GET method because you want ranges of the same resource for which you typically use a GET.  But I think that the semantics of the Range header could also be used with the POST method. The question then is what to post, an empty entity body ?
    And another aspect with regard to security is how to authenticate the pulling endpoint when XML security is used. This would mean that subsequent range requests should include an XML document. If HTTP security is used this would not be a problem.  

    When extending the ebMS protocol for Pulling to allow for partial pulling the PullRequest signal could be extended with a PartialPull element. Then an initial PullRequest to start a partial pull would look like:

    <eb:SignalMessage>
      <eb:MessageInfo>
        <eb:Timestamp>2006-07-25T12:19:05</eb:Timestamp>
        <eb:MessageId>UUID-1@initiator.example.com%3c/eb:MessageId%3e">UUID-1@initiator.example.com</eb:MessageId>
     </eb:MessageInfo>
      <eb:PullRequest mpc="http://msh.example.com/mpc123">
       <eb:PartialPull/>
     </eb:PullRequest>
    </eb:SignalMessage>

    The Responding endpoint then replies with only the only the SOAP envelop which inlcudes the ebMS header. This will inlcude an <eb:UserMessage> element that contains the meta data on the payloads. For example:

    <eb:UserMessage
    mpc="http://msh.example.com/mpc123">
        <eb:MessageInfo>
            <eb:Timestamp>2006-07-25T12:19:06</eb:Timestamp>
            <eb:MessageId>UUID-2@responder.example.com%3c/eb:MessageId%3e">UUID-2@responder.example.com</eb:MessageId>
        </eb:MessageInfo>
        ...
        <eb:PayloadInfo>
                <eb:PartInfo href="cid:foo@example.com"/>
                <eb:PartInfo href=”cid:bar@example.com”/>
        </eb:PayloadInfo>
    <eb:UserMessage>
        
    Now the initiating endpoint can pull parts of the payload using new PullRequests with the PartialPull element specifying what to pull. Such a request would look like:

    <eb:SignalMessage>

     <eb:MessageInfo>
        <eb:Timestamp>2006-07-25T12:19:08</eb:Timestamp>
        <eb:MessageId>UUID-3@initiator.example.com</eb:MessageId>
     </eb:MessageInfo>
      <eb:PullRequest mpc="http://msh.example.com/mpc123">

       <eb:PartialPull>
               <eb:RefToMessageId>UUID-2@responder.example.com</eb:RefToMessageId>
               <!-- Part element can be repeated for pulling parts of multiple payloads -->
                
    <eb:Part href=«reference to payload as included in eb:UserMessage/eb:PayloadInfo[@href]»
                            range=«As specified in RFC2616 (HTTP 1.1)»
              />
               </eb:Part>
      </eb:PartialPull>

     </eb:PullRequest>

    </eb:SignalMessage>

    Response to this request could be only the requested data, without any ebMS and/or SOAP envelop or a complete ebMS header (which could be a recurrence of the original header).
    Using ebMS message to pull parts security can be arrange like normal PullRequests. What needs to be configured in both scenario’s is how long the responding endpoint should retain the data. When the parts are sent within a SOAP envelop RM could be used to ensure successful transmission of the parts and data can be deleted when the part is successfully transmitted.

    The above is only a rough sketch of both options. I can work them out based on discussion tomorrow.

    Regards,
    Sander  

     

    On 06/04/2010 15:36, "ian.c.jones@bt.com" <ian.c.jones@bt.com> wrote:

    Team,

        all times usual.  Any more comments on restart or selective pulling??

    Ian

     -- Ian Jones


    ebXML Messaging TC weekly call has been added by Ian Jones

    Date:  Wednesday, 07 April 2010
    Time:  11:30am - 01:00pm PT

    Event Description:
    ebXML Messaging TC weekly call

    Tel: +1-218-486-8700
    Pass code 120905

    Agenda:
    1. Role
    2. Review of this weeks updates
     Restart (AS2)
     Pulling specific document
    3. AS4 - Updates
    4. A.O.B

    Minutes:


    View event details:
    http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/event.php?event_id=26902

    PLEASE NOTE:  If the above link does 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.