Dear all,
Afraid I
might again not be able to attend today's call - I'm in a meeting and due to
delays it looks like my presentation's going to be at 16:00
.
Susanne
Hi Joao
Thank you for your comments. I have added them to the Wiki page. Looking
forward to the discussion at the meeting.
Best regards,
Kenneth
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
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
fairlysubstantial 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 lightweightand 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 charterdiscussion?
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 subsequentchange 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
thisto 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 beinglightweight. 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 postponethe
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 recharterto 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. ------------------------------------------------------------------------------------------
|