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