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
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
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
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
--
|