← Prev in month
← Prev in thread
AW: [bdx] Proposal for a TC recharter
Mikkel,
Regarding emphasis on the
lightweightedness of the infrastructure you seem primarily to be referring to
the discovery process. I could easily agree to give DNS-based discovery
(SML/SMP) precedence over competing technologies such as UDDI and ebXML RegRep.
(The e-CODEX project and what we call the ?e-Delivery task force? are
particularly interested in how to use SML / SMP with ebMS.) That does however not necessarily exclude examining these other
technologies altogether. As the draft charter says, in some cases different
approaches can be taken into account and even profiled, as a set of base
technologies to choose from. Among the people who created the draft charter
there seemed to be a consensus that the requirements of the LSPs should inform
prioritizing the work, and in fact e-CODEX ? requirements are in many ways
similar to those of PEPPOL.
It will indeed be
necessary to discuss priorities and, as others have mentioned, also timetables,
but that is something that all TC members will have to agree upon, and being the
newbie in this group I will certainly not presume to take a prominent role in
that. I do however offer to take a share in the work.
With the change of
wording you proposed, I see no particular problem.
Looking forward to
working with you in the TC
Susanne
__________________________________________________
Dr.
Susanne Wigard
IT. NRW, Ref. 312
Postfach 101105
40002
Düsseldorf
Phone +49-211-9449-6742
Mobile +49
1735260181
__________________________________________________
Von: Mikkel Hippe Brun
[mailto:]
Gesendet: Freitag, 2. März 2012
10:04
An: Wigard, Susanne (IT.NRW)
Cc:
; ;
;
Betreff: 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, <>
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: [mailto:] Im Auftrag von Mikkel
Hippe Brun
Gesendet: Donnerstag, 1. März 2012
22:28
An: Kenneth Bengtsson
Cc: Tim McGrath; ; 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:
Den 01/03/2012 kl. 21.40 skrev Kenneth Bengtsson
<>:
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 <>
Date: Wed, 29 Feb 2012 22:49:15
+0800
To: "" <>
Cc: Mikkel Hippe Brun <>, Kenneth Bengtsson <>, Jens Jakob Andersen <>
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" <>
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:]
>Sendt: 13. februar 2012
15:58
>Til: Jens Jakob Andersen; Tim McGrath
>Cc:
>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" <>
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:]
>>Sendt:
13. februar 2012 11:22
>>Til: Jens Jakob
Andersen
>>Cc: Kenneth Bengtsson;
>>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:
Web: http://tradeshift.com
-- INVOICING HAS NEVER
BEEN EASIER
--
← Prev in month
← Prev in thread