Re: [ebxml-msg] Large file transmission using AS2 restart

[Sander Fieten <sander@fieten-it.com>]

Title: Re: [ebxml-msg] Large file transmission using AS2 restart

Retrieving a range of bytes from a resource on an HTTP server is already part of the HTTP 1.1 spec by specifying the Range header in the request. To use this functionality in case of message exchanges you must be able to identify the message you want to retrieve the range from. For this the Etag header from the AS2 restart spec could be used. Although this looks similar to push restart I don’t know if it just as easy to implement as the http server has to use the message id to identify the resource being requested. If the id is in an http header it might not recognize it as a separate resource. I don’t know how if it would be easier if the id is part of the URL.

Assuming it can be done with the http header a section to specifiy this could look like:
===

4.4.3.1 ebMS restart 
The AS2-restart specification only allows restart functionality for pushed messages. It is however useful to have restart functionality when pulling large messages. Therefore the restart functionality as specified in the AS2 restart specification is extended here to pulling. To identify this functionality a value of ebms3-restart MUST be set for Pmode[].Protocol.Restart.Protocol.   
When this protocol is used the endpoint responding to a PullRequest MUST include a Etag http header in the response with a unique transfer id. It is RECOMMENDED to use the ebMS MessageId as the transfer id. The pulling endpoint can now restart the pull by sending a HTTP GET (or POST depending on allowed methods) and specifying both the Etag and Range http headers.

=== 

Regards
Sander

On 29/03/2010 18:07, "Moberg Dale" <dmoberg@axway.com> wrote:

Good question.
 
Restart was intended mainly for POST HTTP messaging with the “payload” sent in the POST, not in the response. This can be seen in that the sender (the POSTer) needs to find out from the receiver (using HEAD) how much data was received for an identified payload.
 
In the reverse case (using the “backchannel”) some other solution is needed. GET with a byte range? Re-POST with a payload identifier and something indicating the byte ranged that is still needed?
 

---

From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Sunday, March 28, 2010 10:27 PM
To: timothy@drummondgroup.com
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Large file transmission using AS2 restart


Hello,



AS2 only supports "pushed" messages, and this is what AS2 Restart supports.

A question is whether this mechanism could be used for large "pulled" messages.   



Pim



(I will post an updated version of the spec today or tomorrow)

---

From: Timothy Bennett [mailto:timothy@drummondgroup.com]
Sent: 26 March 2010 16:51
To: Moberg Dale
Cc: Pim van der Eijk; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Large file transmission using AS2 restart
During last Wednesday's discussion on the TC about using AS2 Restart, there were a number of questions raised about the spec that couldn't be answered.  Would you folks that raised questions, please post them here, so that I can submit them to Aaron Gomez here at Drummond Group so that he and Terry Harding (Axway; AS2 Restart spec editor) to brainstorm/prepare responses.

Thanks!

Moberg Dale wrote:
New drafts will be issued until a decision is made about advancing it
through the IETF RFC process. I would have to find out whether there are
any dependencies on existing drafts. But mainly nothing unusual seems to
be in store for the draft's progress because it will meet the IP
policies and it is an informational RFC. Therefore, it does not have to
go through the same reviews as a standards track RFC would go through.
 
-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Wednesday, March 24, 2010 12:01 PM
To: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Large file transmission using AS2 restart
 
 
 
Hello Dale,
 
The draft IETF document expires on April 4th.   What is the
next step for this spec?
 
Pim
 
-----Original Message-----
From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: 24 March 2010 17:13
To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Large file transmission using AS2
restart
 
I asked Terry Harding (author/editor) of the draft and he
and I agree that there is no obstacle in using the procedure
with any HTTP POST based protocol. There is a new HTTP
header with an ID, and there is state to retain on the
receiver(and sender) side. The receiver also needs to
support the HEAD HTTP request.
 
(It also pretends that a GET request on the resource URI
exists and is defined so that it would have a content-length
associated with it that the HEAD requests return. This
content-length number allows the sender to know where to
restart, if necessary.)
 
Remember that the document is currently an Internet-Draft
and not yet a RFC.
 
 
-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Wednesday, March 24, 2010 7:52 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Large file transmission using AS2
restart
 
 
 
Hello,
 
There is a requirement of some potential users of ebMS 3.0
to be able to exchange large files (Gigabytes and larger).
There is a specification for AS2 that offers a "restart"
feature:
http://www.ietf.org/id/draft-harding-as2-restart-00.txt
 
We can borrow this feature for ebMS, and add a mini-section
to chapter 4 that references the AS2 feature. Since we just
reference the IETF RFC, this feature adds just a few lines
of text to the spec. Many multi-protocol B2B products
support this for AS2 already.  It would be minimal effort
for them to enable this for ebMS.  For ebMS users, it adds a
useful capability.  
 
As we did for pipelining, we could add a Pmode parameter to
indicate whether the ebMS MSH supports it or not.  If
"True", clients in HTTP client mode can add the HTTP ETAG
with ebMS messages sent and can use the HTTP HEAD command to
obtain the status of the transfer, as described in the RFC.
If "False", they should not do this. We've added Pipelining
to MEPBinding, and could do the same with "Restart":
 
PMode.MEPbinding.Restart  {True/False}
 
Or we could make it a parameter in PMode.Protocol
 
What do people think?   
 
Pim
 
 
 
 
------------------------------------------------------------
---------
To unsubscribe from this mail list, you must leave the OASIS
TC that
generates this mail.  Follow this link to all your TCs in
OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_work
groups.php
 
 
------------------------------------------------------------
---------
To unsubscribe from this mail list, you must leave the OASIS
TC that
generates this mail.  Follow this link to all your TCs in
OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_work
groups.php
 
 
 
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
 
 
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
 
 
  
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php