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:]
Sent: Tuesday, April 06, 2010 9:30
AM
To:
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>"></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>"></eb:MessageId>
</eb:MessageInfo>
...
<eb:PayloadInfo>
<eb:PartInfo
href="'"/'>"/>
<eb:PartInfo
href="”cid:”/>
</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></eb:MessageId>
</eb:MessageInfo>
<eb:PullRequest mpc="http://msh.example.com/mpc123">
<eb:PartialPull>
<eb:RefToMessageId></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, "" <>
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.
