Public Comment

[comment-form@oasis-open.org]

Comment from: david@drrw.info

Pete,

Thanks for the quick response - here's the summary - and also the link 
to the discussion over
on the BPSS list archive thread on this:

 http://lists.oasis-open.org/archives/ebxml-bp/200410/msg00020.html

Thanks, DW

Pete Wenzel wrote:


>>Hi, David.  Are you proposing the addition of payload references that
>>could be resolved (pulled) by the message recipient?  Is some sort of
>>payload assembly mechanism also required?  Please do provide details.
>>
>>--Pete
>>
>>  
>>

==============================

Defining Staged Delivery.

The following text is intended to quantify 'staged delivery' and understand
the pattern it uses and to be able to specify one of these in a BPSS, and
implement it with CPA / ebMS behaviour level details.

An analogy here may be to the traditional supply chain equivalent being the
ship notice, followed by the delivery notice - but instead of using a truck
to exchange goods - this requires using the ebMS itself since the 'goods'
are electronic content or documents of some form in the electronic message
itself.

There are all kinds of government administrative situations when this
applies - court submissions, bids and proposals, grant award submissions,
responses to demands for technical data, and so on. On the commercial side
would be multimedia content distribution as a use case - where a 
distributor
is sending out large files to subscribers, so they would notify that new
content is ready for delivery, and queue that content, and then the
subscriber could connect and release that exact content to them when they
were ready to do that, or vice versa, subscribers sending in content.

This pattern applies particularly when the message size is extremely large
(relative to the available bandwidth) and there is some deadline or
constraint to its delivery, and there is the potential for the receiver
system to be swapped trying to receive one or more such transmissions 
within
a specific timeframe.

So - in a formal staged delivery, the first email is the key email that
initiates the staging from the sender to the receiver - it contains ticket
information that must be validated by the receiver's backend system that
verifies the sender's submitter information and establishes the
time-of-submission, (as opposed to the final delivery time which may occur
later).  It also contains the metrics about the second message (the "goods"
to be exchanged) that can be used to authenticate that the second message
received is in fact the one referred to in the first ticket and created at
the original time-of-submission.

Therefore the vital thing from the receiver's legal perspective is that the
second email is created and "sealed" at the time the first ticket is sent.
That first ticket must be received prior to the submission deadline date /
time. The second part of the packet is then held in a staging area 
status by
the sender messaging system until the receiver verifies that it's OK to
release it to delivery.

The receiver will confirm back to the sender with a receipt acknowledgement
once the transfer is completed.  The time to perform would be set at some
length of time appropriately, but could be several elapsed days.  Any
subsequent exchanges would be a new or follow-on business transaction
activity; such as correcting errors in the second transmission content
itself, or providing additional information.