Re: [bdx] Proposal for a TC recharter

I do support the change to the TC's charter if it means wider support to the TC's work from the other large scale pilots. I do however have concerns about the widening of the scope as it will impact the speed with which the TC can work (Mike's argument).

One important criteria that is fundamental for the large scale pilots mentioned in the charter is that there is very little willingness to establish and fund more than the most essential shared infrastructure components. It is therefore in my opinion very important that the technologies that the TC explores for service discovery and addressing piggybacks on existing Internet infrastructure like DNS.

I don’t find UDDI or ebXML RegRep to be operational and scalable for large scale infrastructures. We may as a TC and individuals find the standards behind UDDI or ebXML RegRep to be appropriate, but the reference implementations are not battle proven for large scale use. And it is my very strong opinion that the TC should focus on technologies that are battle proven and can be put into use immediately.

Finally - I would like to step down as chair for the TC, but I would like to continue as TC member.

On Tuesday, February 21, 2012, Kenneth Bengtsson wrote:

Hi Jens Jakob

I very much agree with you that this is an important design goal and
objective for a number of applications (PEPPOL for example). At the same
time I also believe we must acknowledge that other applications can have
different requirements and implementation architectures.

One of the important reasons for the proposed recharter is to allow for a
broader and more general application of the BDX specifications. This
doesn't mean that we in PEPPOL will accept to have specific protocol
requirements imposed on the "final leg" between gateway and enduser, I
strongly agree with you on this. What it means is that we see an advantage
in opening up the possible use cases for BDX, and not let the requirements
of one project stand in the way of a more broad adoption.

Best regards,

Kenneth

On 2/20/12 8:15 AM, "Jens Jakob Andersen" <jjan@itst.dk> wrote:

>Hi Kenneth
>
>Thank you for the clarifications.
>
>I still cant see in the specs, that is is a _must_, that the protocols to
>be used between gateways must be agnostic to whatever is used on the
>first & last legs.
>
>Some of the "GW to GW" protocols I have seen demonstrated, has many
>features that can only be usefull, when the same family of protocol is
>used end-2-end.
>
>The original design-goal of BDX was to deliver a "meta-protocol" to be
>used between gateways - to interconnect different domains. And supporting
>many different transport-protocols below.
>
>From my (fast fading viewpoint as I am leaving the TC), these
>design-goals should be kept as the TC's design-goals.
>
>Best regards
>
>Jens Jakob
>
>-----Oprindelig meddelelse-----
>Fra: Kenneth Bengtsson [mailto:kenneth@alfa1lab.com]
>Sendt: 13. februar 2012 15:58
>Til: Jens Jakob Andersen; Tim McGrath
>Cc: bdx@lists.oasis-open.org
>Emne: Re: SV: [bdx] SV: Proposal for a TC recharter
>
>Hi Jens Jakob
>
>As Tim already mentioned, the 4-corner model is described already in the
>first paragraph.
>
>With regards to "connecting islands":
>
>In the first paragraph is stated that BDX describes a model "where two
>entities exchange business documents in a secure and reliable way through
>the use of gateways". If we can agree that it is in the definition of a
>gateway that it has two sides, then it is in logic that the two entities
>exchanging business documents must each connect to their respective
>gateways, and that the gateways must connect to one another. Then you
>have the first, the last, and the middle "leg" of the transaction. If you
>read the second and third paragraph of the statement of purpose and
>replace "domain" with "island", then I think you will agree that it is
>actually in the proposed purpose statement to "connect different islands
>of networks".
>It is my understanding that the term "island" is mainly used in
>procurement jargon, why we have used the more generic term "domain" to
>describe exactly the same. This is also to signal that the potential use
>of BDX goes beyond procurement and e-commerce business documents - BDX
>can be used for any type of electronic business document.
>
>Best regards,
>
>Kenneth
>
>
>On 2/13/12 9:44 AM, "Jens Jakob Andersen" <jjan@itst.dk> wrote:
>
>>Hi Tim
>>
>>Thank you for the clarification.
>>
>>That is half of it.
>>
>>What I am looking for is the other part of the 4-corner model, that
>>different protocols can be used on the "first leg" and "last leg" and
>>the "inbetween" part can be a standardized "meta-protocol" such as
>>START - open for mapping to "any" actual protocol.
>>
>>This is the core of the idea of START /and BusDox and BDX/ - that the
>>challenge is to "connect different islands of networks".
>>
>>The acid-test for any change should (IMHO) be: "Can it deliver the
>>value mentioned, in a setup with different protols/implementations on
>>the first and last leg".
>>
>>Best regards
>>
>>Jens Jakob
>>
>>-----Oprindelig meddelelse-----
>>Fra: Tim McGrath [mailto:tim.mcgrath@documentengineeringservices.com]
>>Sendt: 13. februar 2012 11:22
>>Til: Jens Jakob Andersen
>>Cc: Kenneth Bengtsson; bdx@lists.oasis-open.org
>>Emne: Re: [bdx] SV: Proposal for a TC recharter
>>
>>it is in the statement of purpose.
>>> The BDX standard will describe an architecture (or sets of reference
>>>architectures) where two entities exchange bu

bdx message