Hi Pim,
Thank you for kicking the discussion off. See my comments inline below:
On Wed, Mar 30, 2011 at 12:24 PM, Pim van der Eijk <> wrote:
I have not studied this document fully, but here are some
comments:
1) I would recommend starting to use the OASIS specification
templates as soon as possible, to save yourselves a lot of editing time later
..
Agree - I have requested a template from OASIS. You cannot download them anymore. They will create a template for us.
2) In an architecture of 4 corner document exchange, I would
have expected to see an explanation or justification of a 4 corner model of
communication, and the requirements it addresses. Instead, the
introduction starts with a sweeping statement: "It is widely recognized that the
4-corner model is the right model for secure and reliable exchange of business
documents between business partners". I'm not saying I
diagree. But given that there has been a massive shift away from service
provider-based models to peer-to-peer communication and the success
of protocols like AS2, this statement deserves more justification.
Point taken. Lets elaborate on this.
3) The document proposes that all Access Points
must support a default transport protocol and proposes a specific transport
protocol. We discussed this in the past, and then it
was agreed that we would leave such decisions to conformance
clauses/profiles. Multiple conformance profiles could make different
choices.
I agree that we should leave the decision of which transport protocol to use to the service providers deciding to implement a BDX Infrastructure Instance. However - I believe that we should state that "There MUST be a default transport protocol in a BDX compliant solution".
Any proposed default for transport protocol would
need to be justified, e.g. established market share among service providers
would perhaps favour adopting AS2 as default protocol since it is the most
widely used B2B transport protocol in many parts of the
world.
I agree that we should leave the choice of protocol to the service providers.
4) The document also proposes a participant
identifier scheme that combines scheme identifier and identifier code. I'm
not sure why the specifics of identifier schemes needs to be discussed in an
architecture document. There are some ISO standard scheme catalogs, such as
6523, 20022, 9735. There is also an established OASIS
party identifier which has been used for some years and is seeing increased
adoption:
http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/
I'm not sure why a new method of concatenating catalog
identifier, scheme identifier and scheme-specific identifier is
needed.
Pim
From: Mikkel Hippe Brun
[mailto:]
Sent: 30 March 2011 10:56
To:
Business Document Exchange TC List
Subject: [bdx] New version of BDEA
uploaded
If you have time before the BDX meeting later today. Take a look at
the following sections:
Overview
A model for re-using existing identifier schemes
Trust and security
Download Document:
http://www.oasis-open.org/committees/download.php/41668/Business_Document_Exchange_Architecture_BEDA_v0p3.pdf
Best
regards,
Mikkel
Mikkel Hippe Brun
Voice: +45 3118
9102
Skype: hippebrun
Twitter: @hippebrun @tradeshift
Mail:
Web: http://tradeshift.com
