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</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=""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.