Re: [bdx] Proposal for a TC recharter

[joao.frade@pwc.be]

Hello Kenneth and all,

I suggest the following 2 changes to
the TC's statement of purpose.

...in the area of e-government [1]
such as PEPPOL, e-CODEX and SPOCS. [2] The TC will
contribute to the ongoing convergence of Pan-European messaging and trust
infrastructures for reliable data exchange.

Rational:

[1] I believe that we could eventually
take into account requirements coming from epSOS  or other large Pan-European
initiatives
[2] I believe that this clarifies what
we mean by "address requirements from the Large Scale Pilots".

We can discuss,

Joao Frade
PwC | Senior Manager
Direct: +32 2 7109284 | Mobile: +32 477 842292 | Fax: +32 2 7107224
Email: joao.frade@pwc.be
PwC Enterprise Advisory cvba/scrl
Firm legal information, click here

Kenneth Bengtsson <kenneth@alfa1lab.com>
Sent by: <bdx@lists.oasis-open.org>

13/03/2012 05:29

To	Kenneth Bengtsson <kenneth@alfa1lab.com>, Roger Bass <roger@traxian.com>, <Susanne.Wigard@it.nrw.de>, Mikkel Hippe Brun <mhb@tradeshift.com>
cc	Tim McGrath <tim.mcgrath@documentengineeringservices.com>, <bdx@lists.oasis-open.org>, Jens Jakob Andersen <jjan@itst.dk>
Subject	Re: [bdx] Proposal for a TC recharter

Dear TC

Prior to our meeting on Wednesday to discuss
the proposed TC recharter I have updated the Wiki page to reflect the discussion
here on the list:

http://wiki.oasis-open.org/bdx/Recharter

I have added the change proposed by Mikkel
(with the modification as proposed by Roger). No further changes to the
original proposal have been received so far. If there are any further comments
or suggestions for changes, please send them to the list or update the
Wiki page before the Wednesday meeting.

Best regards,

Kenneth


From: Kenneth Bengtsson <kenneth@alfa1lab.com>
Date: Mon, 05 Mar 2012 22:49:14 -0500
To: Roger Bass <roger@traxian.com>,
<Susanne.Wigard@it.nrw.de>,
Mikkel Hippe Brun <mhb@tradeshift.com>
Cc: Tim McGrath <tim.mcgrath@documentengineeringservices.com>,
<bdx@lists.oasis-open.org>,
Jens Jakob Andersen <jjan@itst.dk>
Subject: Re: [bdx] Proposal for a TC recharter

Dear Roger

Sorry - I didn't mean to ignore to your
comments about "web services", I just had in my head that they
were included in the broad definition of messaging services. I guess I
don't see the need for mentioning web services specifically as clearly
as you do. But I trust your instinct, and I can support your wording below.

Best regards,

Kenneth


From: Roger Bass <roger@traxian.com>
Date: Mon, 5 Mar 2012 15:36:53 -0800
To: <Susanne.Wigard@it.nrw.de>,
Mikkel Hippe Brun <mhb@tradeshift.com>,
Kenneth Bengtsson <kenneth@alfa1lab.com>
Cc: Tim McGrath <tim.mcgrath@documentengineeringservices.com>,
<bdx@lists.oasis-open.org>,
Jens Jakob Andersen <jjan@itst.dk>
Subject: RE: [bdx] Proposal for a TC recharter

Susanne, Kenneth, Mikkel
et al,
 
How about: “…data exchange,
messaging and web services interoperability between domains”?
 
To your question, Susanne,
I’d use the Internet as an analogy for how the notions of extension and
limitation relate to one another in this interoperability context.  Indeed,
as you say, on one level, we don’t care what we are interconnecting, just
as the Internet was about making networks of all kinds interoperable, regardless
of their many different internal protocols.  However, the means by
which that was realized for networking was one tightly-defined, *lightweight*
stack of standards (TCP/IP, DNS, SMTP) with *just enough* functionality
that “gateways” or “routers” implementing that stack were able to deliver
that universal interoperability.
 
I think a similarly universal
stack of lightweight, tightly-defined, just-functional-enough standards
will emerge in this space – perhaps, I hope, from this BDX effort.  The
key, I think, is in determining what is “just enough” to achieve fairly
universal interoperability.  Since much of the work in recent years
on interoperability has been under the ‘web services’ banner, it seems
to me important to include that in the TC’s interoperability goal *regardless
of what an eventual, tightly-defined standards stack looks like*.
 
Mikkel, to your point, AMQP
feels to me like it fits within the scope of ‘web services’, broadly
defined (and, indeed, messaging).  SFTP I personally would not consider
as ‘web services’ but would include under ‘messaging’.  I agree
that the ability to describe an SFTP endpoint could be within scope.
 
Best,
Roger
 
 
From: Susanne.Wigard@it.nrw.de
[mailto:Susanne.Wigard@it.nrw.de]
Sent: Monday, March 05, 2012 1:54 PM
To: roger@traxian.com;
mhb@tradeshift.com;
kenneth@alfa1lab.com
Cc: tim.mcgrath@documentengineeringservices.com;
bdx@lists.oasis-open.org;
jjan@itst.dk
Subject: AW: [bdx] Proposal for a TC recharter
 
Roger, 
 
You explicitly say that adding
the term 'web services' is to extend rather than limit the concept of data
exchange. However this is (at least from a layman's perspective) precisely
not the impression it is conveying. In my ears "web services interoperability"
is about connecting web services (or even Web Services), whereas the very
point of what we are doing is we don't care about *what* we are interconnecting
(or so I thought). Just my two cents. 
 
Susanne

---

Von: Roger Bass [mailto:roger@traxian.com]
Gesendet: Montag, 5. März 2012 19:05
An: 'Mikkel Hippe Brun'; 'Kenneth Bengtsson'
Cc: Wigard, Susanne (IT.NRW); 'Tim McGrath'; bdx@lists.oasis-open.org;
'Jens Jakob Andersen'
Betreff: RE: [bdx] Proposal for a TC recharter
Kenneth, Mikkel,
 
I won’t belabor the point
much further, but it seems to me the already agreed scope here is more
than just “messaging service interoperability”.  SML/P (and indeed
CPPA) are about interoperability at the level of business capabilities
to exchange very specific types of data (invoice, order… and doubtless
other types in the eCODEX domain).  Kenneth, you didn’t comment specifically
on leaving out “web services”.
 
I think Mikkel’s points
emphasizing the “lightweight” requirement are well made, and I’m certainly
not arguing for any particular heavyweight standard from the Web Services
domain.  I see it as a broader issue.  Rightly or wrongly, leaving
out ‘web services’ contributes, I think, to a continuing impression that
the TC is reluctant to even consider leveraging or aligning with the fairly
substantial related efforts to date elsewhere, in particular around web
services (lower case!) and SOA more broadly, and even if that’s a longer
term goal.
 
If I’m the only person thinking
like this on ‘web services’ then I’ll drop the point, but I’d be interested
in hearing specific arguments for excluding it.
 
Best,
Roger
 
From: bdx@lists.oasis-open.org
[mailto:bdx@lists.oasis-open.org]
On Behalf Of Mikkel Hippe Brun
Sent: Monday, March 05, 2012 8:42 AM
To: Kenneth Bengtsson
Cc: Roger Bass; Susanne.Wigard@it.nrw.de;
Tim McGrath; bdx@lists.oasis-open.org;
Jens Jakob Andersen
Subject: Re: [bdx] Proposal for a TC recharter
 
I am very happy with the proposed
change.
 
Regards
Mikkel
On Mon, Mar 5, 2012 at 5:03 PM,
Kenneth Bengtsson <kenneth@alfa1lab.com>
wrote:
Dear all
 
Good idea with the Wiki. I will follow
up on that.
 
I'm also in agreement with Mikkel's comments
and in general I support the proposed changes. However I also think that
"interoperability" is an important aspect of the work of the
TC and shouldn't be removed entirely. One could say that to "exchange
data between domains" interoperability is implicit, but I still think
we could benefit from emphasizing it. I would be fine with:
 
Proposed:
The purpose of the TC is therefore to define
the specifications of a lightweight
and federated messaging and trust
infrastructure for reliable data exchange and messaging services
interoperability between domains.
 
Best regards,
 
Kenneth
 
 
From: Roger Bass <roger@traxian.com>
Date: Sun, 4 Mar 2012 21:19:42 -0800
To: Mikkel Hippe Brun <mhb@tradeshift.com>,
<Susanne.Wigard@it.nrw.de>
Cc: Kenneth Bengtsson <kenneth@alfa1lab.com>,
Tim McGrath <tim.mcgrath@documentengineeringservices.com>,
<bdx@lists.oasis-open.org>,
Jens Jakob Andersen <jjan@itst.dk>
Subject: RE: [bdx] Proposal for a TC recharter
 
Kenneth, Susanne, Mikkel
et al,
 
My apologies too, belatedly,
for missing the last meeting – I look forward to the next one.  Given
the ongoing discussions and emails about potential edits, I wonder if it
would be helpful to leverage the OASIS wiki infrastructure for this charter
discussion?  Keeping track via of proposed changes all the emails
is challenging.  I did just verify that no OASIS wiki has yet been
set up for BDX.  Kenneth, as the new chair, would you be able to request
this from the TC-Admin?  Ideally perhaps, the wiki might show the
draft charter as you originally submitted it, Kenneth, with each subsequent
change noted separately.
 
As to the specifics of Mikkel’s
proposals: adding “lightweight” and “reliable” seem good to me.
 
I’m less comfortable with
removing “web services interoperability”.  I agree we shouldn’t
limit ourselves to “Web Services” in the formal, capitalized sense.  However,
as originally written here, I think the sense of adding that term is to
*extend* rather than *limit* the concept of data exchange.
 Using lower case, I think, also implies we’re not limiting this
to the WS-* stack (RESTful web services etc included, for example).  And
while I’m aware that OASIS has taken on the WS-I work, my understanding
is that that was more narrowly scoped, and is now in maintenance mode.
 ‘Web services’ is also an important, descriptive term used for
much related work in this domain, and I think it’s helpful to point that
out here. 
 
Best regards,
Roger
 
 
From: bdx@lists.oasis-open.org
[mailto:bdx@lists.oasis-open.org]
On Behalf Of Mikkel Hippe Brun
Sent: Friday, March 02, 2012 1:04 AM
To: Susanne.Wigard@it.nrw.de
Cc: kenneth@alfa1lab.com;
tim.mcgrath@documentengineeringservices.com;
bdx@lists.oasis-open.org;
jjan@itst.dk
Subject: Re: [bdx] Proposal for a TC recharter
 
Thank you for this clarification
Susanne. I am very exited about the prospect of getting new resources into
the TC. I have re-read the proposed charter multiple times and I can see
where you are coming from and that you really intend to make the TC very
operational. 
 
The only thing I miss from the
old charter is the emphasis on the resulting infrastructure in itself being
lightweight. It also follows from the infrastructure being federated, but
the critical part is that any centralized infrastructure components have
as little footprint as possible. The more we can piggybag on existing infrastructure
the better. Such a framing would also scope discussions about service discovery
and addressing specifications like UDDI and ebXML RegRep.
 
I would then sugges the following
change to the proposed charter:
 
Original: 
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.
 
Proposed:
The purpose of the TC is therefore
to define the specifications of a lightweight
and federated messaging
and trust infrastructure for reliable data exchange between domains.
 
I have taken out the "web
services interoperability" because this is covered by other OASIS
TC's and I dont think that we should limit ourselvs to web services (in
the classical sence). The old charter mentioned "messaging service
standards" and I think this term covers the intention better.
 
All the best
Mikkel 
 
 
 
On Thu, Mar 1, 2012 at 11:01 PM,
<Susanne.Wigard@it.nrw.de>
wrote:
Dear all,
 
First let me apologize for failing
to join the telco. I'll have more comments when I get to see the minutes
- for now let me just emphasize that indeed the intention of broadening
the scope goes anlong with the goal to add resources to the TC, in particular
from the LSP project that I'm working with, e-CODEX, and connected to activities
in the context of creating a common transport infrastructure for the ongoing
and future LSPs. So it's not about disreagrding the PEPPOL work, but quite
to the contrary about continuning it into new projects and domains. 
 
Regards
 
Susanne
____________________________________
Susanne Wigard
Phone +49-211-9449-6742
Mobile +49
1735260181

---

Von: bdx@lists.oasis-open.org
[mailto:bdx@lists.oasis-open.org]
Im Auftrag von Mikkel Hippe Brun
Gesendet: Donnerstag, 1. März 2012 22:28
An: Kenneth Bengtsson
Cc: Tim McGrath; bdx@lists.oasis-open.org;
Jens Jakob Andersen
Betreff: Re: [bdx] Proposal for a TC recharter
Thank you for the clarification
Kenneth. This sounds very good and I look forward to the continued discussion
and the next meeting. 

Regards / Hilsen 
Mikkel
Cell: +45
31189102
Mail: mhb@tradeshift.com

Den 01/03/2012 kl. 21.40 skrev Kenneth Bengtsson <kenneth@alfa1lab.com>:
Dear Tim and Mikkel
 
I agree with your comments, and
it was as such also the intention with the proposed charter to reflect
these viewpoints. I'm sure the wording can be improved:
 
In the statement of purpose it
says that TC specifications should be...
"...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.".
The intended meaning of this is,
exactly as both of you commented: To focus on technologies that already
exist and can be put into immediate use in the work of the TC.
 
Also in the statement of purpose:
"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 intended meaning here is to
say: We will leverage the work already done by PEPPOL and other LSPs -
this is our starting point. However, if along the way we accept specific
requirements or if we see that our work can benefit from it, then we shouldn't
by default disregard other technologies. We have a solid starting point
with the work already produced by the LSPs and it is from there that we
progress. However we shouldn't progress wearing blinkers.
 
In the scope of work is specifically
mentioned that the specifications from PEPPOL (namely SML, SMP, START and
LIME) will have their home in the TC. The SML/SMP technology are the foundation
for discovery, whereas START and LIME may have more PEPPOL-specific uses.
I'd like to stress again that it is not the intention to disregard the
work already produced.
 
I'm sure that the wordings in the
proposed charter can be improved to better reflect the intended meaning.
There is no pride in ownership, so please feel free to make all the suggestions
for improvement that you like! At yesterday's meeting we agreed to postpone
the vote for the recharter until March 14 to allow for comments and specific
proposals.
 
With regards to the "speed
with which the TC can work": Mike made the comment yesterday that
broadening the scope of the TC means that more work has to be produced,
and that adding more resources is by no means a guarantee that work will
progress any faster. This is a valid comment and it is in most cases true.
However, in our specific case it is a specific objective with the recharter
to make the TC a platform for producing specifications for an ongoing convergence
of the LSPs respective eDelivery technologies. A widening of the scope
will therefore enable the LSPs to add resources to the TC and to take a
leading role. As the LSPs are also working with milestones and deadlines
I do in fact believe that the proposed recharter will make the TC gain
momentum rather than loosing it.
 
Joao volunteered yesterday to make
a suggestion to the proposed charter for clarifying/underlining the role
and significance of the LSPs (and the LSP convergence process) in the TC.
 
Best regards,
 
Kenneth
 
 
From: Tim McGrath <tim.mcgrath@documentengineeringservices.com>
Date: Wed, 29 Feb 2012 22:49:15 +0800
To: "bdx@lists.oasis-open.org"
<bdx@lists.oasis-open.org>
Cc: Mikkel Hippe Brun <mhb@tradeshift.com>,
Kenneth Bengtsson <kenneth@alfa1lab.com>,
Jens Jakob Andersen <jjan@itst.dk>
Subject: Re: [bdx] Proposal for a TC recharter
 
I also have a call conflict for
today's call. i support Mikkel's view on this - the rechartering is a good
step forward, but there is a risk of loosing momentum.  We should
be capitalizing on the progress PEPPOL and other LSPs have made in this
area.  That is, we should be building on what we have, not what we
would like to see.

On 29/02/12 10:28 PM, Mikkel Hippe Brun wrote: 
Dear all,
I will unfortunately be in transit during
todays call due to a delayed flight.
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.
 
Best regards
Mikkel
 

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


-- 
Best regards,
Mikkel

Mikkel Hippe Brun
Chief Strategy Officer, Cofounder

Voice: +45
3118 9102
Skype: hippebrun
Twitter: @hippebrun  @tradeshift
Mail: mhb@tradeshift.com
Web: http://tradeshift.com

-- INVOICING HAS NEVER BEEN EASIER --
 
 


*Professional Mail*------------------------------------------------------------------------------------------
This e-mail is intended only for the person to whom it is addressed.
If an addressing or transmission error has misdirected this e-mail,
please notify the author by replying to this e-mail. If you are not
the intended recipient you must not use, disclose, copy, print or
rely on this e-mail.
 
PwC may monitor outgoing and incoming e-mails and
other telecommunications on its e-mail and telecommunications systems.
------------------------------------------------------------------------------------------