Re: SV: SV: [bdx] SV: Proposal for a TC recharter

[Kenneth Bengtsson <kenneth@alfa1lab.com>]

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 business documents in a
>>>secure and reliable way through the use of gateways (sometimes also
>>>referred to as access points), which is also known as the "four-corner
>>>model"
>>
>>
>>On 13/02/12 10:57 AM, Jens Jakob Andersen wrote:
>>> Hi Kenneth and others
>>>
>>> Thank you for presenting this charter as the next step.
>>>
>>> When I read it - I cant find the 4-corner model mentioned - as well
>>>as the original notion that the important design-goal is to connect
>>>"islands of networks" - i.e. the importance that we deliver a model
>>>that can work across different networks/protocols.
>>>
>>> Can some of the authors kindly update me where we find the 4-corner
>>>model in this new charter - as well as the important capabilit of
>>>being protocol-neutral? I might have overlooked it and just need
>>>guidance.
>>>
>>> Best regards
>>>
>>> Jens Jakob
>>> ________________________________________
>>> Fra: bdx@lists.oasis-open.org [bdx@lists.oasis-open.org] P&#229;
>>> vegne af Kenneth Bengtsson [kenneth@alfa1lab.com]
>>> Sendt: 12. februar 2012 17:47
>>> Til: bdx@lists.oasis-open.org
>>> Emne: [bdx] Proposal for a TC recharter
>>>
>>> Dear BDX TC
>>>
>>> To move the work of the TC into a broader scope and to accommodate
>>>requirements raised by BDX adopters, some members of the TC have
>>>worked out a proposal for a rechartering of the OASIS Business
>>>Document Exchange TC. The proposal for the rechartering is submitted
>>>in accordance with the OASIS TC Process section 2.12:
>>>
>>> http://oasis-open.org/policies-guidelines/tc-process#rechartering
>>>
>>> The proposed new charter is being submitted by the following members
>>>of the TC:
>>>
>>> Roger Bass, Traxian
>>> Kenneth Bengtsson, Alfa1lab
>>> Pim van der Eijk, Sonnenglanz Consulting Klaus Vilstrup Pedersen,
>>> Difi-Agency for Public Management and eGovernment Sven Rasmussen,
>>> Danish Ministry of Science, Technology and Innovation Susanne Wigard,
>>> Land Nordrhein-Westfalen
>>>
>>> We kindly request that the TC chairs arrange for a TC meeting the
>>>week of February 27 2012 to discuss the proposed new charter below.
>>>Depending on the outcome of these discussions we can proceed to
>>>formally adopt the changes using the process described in the OASIS TC
>>>Process.
>>>
>>> ====================================================
>>>
>>> Name of TC:
>>> OASIS Business Document Exchange TC
>>>
>>> Statement of Purpose:
>>> The BDX standard will describe an architecture (or sets of reference
>>>architectures) where two entities exchange business documents in a
>>>secure and reliable way through the use of gateways (sometimes also
>>>referred to as access points), which is also known as the "four-corner
>>>model".
>>>
>>> The purpose of the TC is therefore to define the specifications of a
>>>federated messaging and trust infrastructure for data exchange and web
>>>services interoperability between domains. Here, a "domain" can be any
>>>community whose members (a) are connected through a shared system, and
>>>(b) may interact with others across domains.
>>>
>>> Regardless of each domain's internal workings, such interactions
>>>entail them each consuming and exposing to others over the Internet
>>>certain interfaces. These specifications should provide a framework
>>>for domains to interoperate securely and reliably (via Web Services),
>>>which can therefore be viewed as an Inter-cloud Web Services framework.
>>>
>>> The TC specifications should be lightweight but, wherever and to the
>>>extent possible, based on profiles of existing standards from OASIS
>>>and elsewhere that are widely-used and proven, or otherwise seen to be
>>>generally applicable.  Approaches that are modular and agnostic about
>>>data content and implementation architectures will be preferred.
>>>
>>> The TC will focus first on requirements for exchanges between groups
>>>of related domains around standardized processes/data. Requirements of
>>>cross-domain business documents exchange, with its corresponding use
>>>cases, and implied interoperability requirements will inform
>>>prioritization of the TC's initial deliverables. The TC will
>>>specifically address requirements from the Large Scale Pilots ("LSPs")
>>>in the area of e-government PEPPOL, e-CODEX and SPOCS.
>>>
>>> In certain areas the work will therefore initially be centered on the
>>>work of these LSPs (notably on SMLP around identity and service
>>>discovery, addressing and profiling), and will also consider other
>>>approaches and related specifications (e.g. DNS, ebXML CPA, UDDI,
>>>ebXML RegRep, WS-Discovery), The TC may define or profile more than
>>>one such specification(s).
>>>
>>> In other areas, published specifications today may be absent or have
>>>gaps.  In such cases the TC will attempt to identify relevant
>>>standards or work-in-progress at OASIS or other SDOs to establish
>>>liaisons with and provide requirements for such efforts, as needed.
>>>
>>> Scope of work of the TC:
>>> The specific objectives will be to define, specify and maintain the
>>>following:
>>>
>>> 1) Use cases and requirements, based on submissions;
>>>
>>> 2) Profiling / gap analysis of existing standards with reference to
>>>the use cases and requirements, potentially including:
>>>    a) Addressing / Routing / Discovery (SML and related technologies)
>>>    b) Service profiles/Capabilities (SMP, CPA and others)
>>>    c) Identity/Authentication
>>>    d) Trust Frameworks
>>>    e) Transport / Reliable Messaging (e.g. AS4)
>>>
>>> 3) Unified architecture for all processes necessary and sufficient
>>> for the superset of supported use cases;
>>>
>>> 4) Specifications for SML/SMP will be developed within the TC;
>>>
>>> 5) PEPPOL specifications for the START and LIME protocols.
>>>
>>> List of deliverables:
>>> Technical specifications for protocols supporting distributed
>>>discovery of locations and e-business and technical capabilities of
>>>exchange partners.
>>>
>>> Profiles of B2B messaging protocols for use in four-corner (or
>>>multi-corner) topologies.
>>>
>>> IPR Mode under which the TC will operate:
>>> The TC will operate under the Non-Assertion Mode.
>>>
>>> The anticipated audience or users of the work:
>>> The initial target groups for the TC are:
>>>
>>>    - Enterprise procurement vendors and supplier networks
>>>    - Software companies (e.g. providers of middleware and business
>>>applications)
>>>    - Supplier information management providers
>>>    - Public institutions
>>>    - Financial institutions and payment networks
>>>    - Large private companies
>>>
>>> Language of the Technical Committee:
>>> The business of the Technical Committee will be conducted in English.
>>>
>>> Liaisons:
>>> The initial list of liaisons that will be established includes: OASIS
>>>ebXML Technical Committees, ETSI ESI and OASIS Identity in the Cloud TC.
>>>
>>> Other liaisons will be established in the course of the work.
>>>
>>> ====================================================
>>>
>>> Best regards,
>>>
>>> Kenneth Bengtsson
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org
>>> For additional commands, e-mail: bdx-help@lists.oasis-open.org
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org
>>For additional commands, e-mail: bdx-help@lists.oasis-open.org
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: bdx-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: bdx-help@lists.oasis-open.org
>