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

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

Title: 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</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>
    </eb:MessageInfo>
    ...
    <eb:PayloadInfo>
            <eb:PartInfo href="'foo@example.com"/'>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.