[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Large file transmission using AS2 restart
|
Please
review section 4.4.3 and let us know:
1)
Assuming Pmode.[1].Protocol.Restart set to True
and
Pmode.[1].Protocol.Restart.Protocol set to
'as2-restart", is
Pmode.[1].Protocol.Restart.Interval the only
relevant configuration / agreement parameter? We discussed an
interval between each restart as separate parameter, but after the call I
thought an interval for the first to last restart covers all that is
needed.
2) Can
AS2 Restarts be adapted to support situations where the restart is initiated by
the message responder rather than the initiator? See discussion
below.
3)
ebMS 3.0 also supports SMTP as a transport protocol, in fact some of the early
ebMS 3.0 users are using this instead of HTTP. Is there an
AS2 restart-like protocol for AS1 ? There is RFC 1845 for SMTP,
but it is from 1995 and still "experimental".
Pim From: Aaron [mailto:aaron@drummondgroup.com] Sent: 29 March 2010 20:55 To: 'Pim van der Eijk'; 'Moberg Dale'; timothy@drummondgroup.com Cc: ebxml-msg@lists.oasis-open.org Subject: RE: [ebxml-msg] Large file transmission using AS2 restart All, What specific questions
were discussed last week in regards to AS2 Restart proper? My
understanding is that there were questions for instances if messages expire?
Any others? Aaron
Gomez DGI From: Pim van der
Eijk [mailto:pvde@sonnenglanz.net] In the update (v56) I
just posted, I've added a restriction to "push" mode when using AS Restart, to
be able to use this feature without modification. And left open the
possibility to specify other transport-level restart mechanisms. AS2
Restart will still be useful for ebMS since deployments where this feature is
needed will typically not be the small companies that motivated "pull" but
medium or large organizations, so in practice many of the intended users would
be served. But perhaps we should
still to a SOAP-level chunking/splitting mechanism to get a really general
solution. Pim From: Moberg Dale
[mailto:dmoberg@axway.com] 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] 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: 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. New drafts will be issued until a decision is made about advancing itthrough the IETF RFC process. I would have to find out whether there areany dependencies on existing drafts. But mainly nothing unusual seems tobe in store for the draft's progress because it will meet the IPpolicies and it is an informational RFC. Therefore, it does not have togo 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 PMTo: [email protected]Subject: RE: [ebxml-msg] Large file transmission using AS2 restart Hello Dale,The draft IETF document expires on April 4th. What is thenext step for this spec?Pim-----Original Message-----From: Sent: 24 March 2010 17:13To: Pim van der Eijk; [email protected]Subject: RE: [ebxml-msg] Large file transmission using AS2restartI asked Terry Harding (author/editor) of the draft and heand I agree that there is no obstacle in using the procedurewith any HTTP POST based protocol. There is a new HTTPheader with an ID, and there is state to retain on thereceiver(and sender) side. The receiver also needs tosupport the HEAD HTTP request. (It also pretends that a GET request on the resource URIexists and is defined so that it would have a content-lengthassociated with it that the HEAD requests return. Thiscontent-length number allows the sender to know where torestart, if necessary.)Remember that the document is currently an Internet-Draftand not yet a RFC.-----Original Message-----From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]Sent: Wednesday, March 24, 2010 7:52 AMTo: [email protected]Subject: [ebxml-msg] Large file transmission using AS2restart Hello,There is a requirement of some potential users of ebMS 3.0to 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.txtWe can borrow this feature for ebMS, and add a mini-sectionto chapter 4 that references the AS2 feature. Since we justreference the IETF RFC, this feature adds just a few linesof text to the spec. Many multi-protocol B2B productssupport this for AS2 already. It would be minimal effortfor them to enable this for ebMS. For ebMS users, it adds auseful capability. As we did for pipelining, we could add a Pmode parameter toindicate whether the ebMS MSH supports it or not. If"True", clients in HTTP client mode can add the HTTP ETAGwith ebMS messages sent and can use the HTTP HEAD command toobtain the status of the transfer, as described in the RFC.If "False", they should not do this. We've added Pipeliningto MEPBinding, and could do the same with "Restart":PMode.MEPbinding.Restart {True/False}Or we could make it a parameter in PMode.ProtocolWhat do people think? Pim---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASISTC thatgenerates this mail. Follow this link to all your TCs inOASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASISTC thatgenerates this mail. Follow this link to all your TCs inOASIS 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 thatgenerates 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 thatgenerates 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]