[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-msg] minutes of nov-13 f2f meeting
OASIS Messaging TC Face 2 Face Nov 13-15, 2001
November 13, 2001
- Role
East Coast
Dan Weinreb
Ian Jones
Ralph Berwanger
Colleen Evans
Bruce Pedretti
Shirley Wu - non-voting
Sally Wang - non-voting
Chris Ferris
West Coast
David Burdett
David Fischer
Doug Bunting
Brian Gibb
Brad Lund
Iwasa
Dale Moberg
Jaques Durand - non-voting
Jeff Turpin - non-voting
Cliff Collins - non-voting
Hima
Arvola Chan
- Selection of secretary - Chris volunteers for 13th
- David Burdett - reverse routing proposal, lengthy discussion. move to
reconsider for v2.0.
Lunch/Breakfast
- motion raised by David F, do we remove TraceHeaderList? Ralph seconds.
discussion:
Sybase indicates that they do use THL for the Sender URL to
respond to PING
in a manner similar to what DB described in his reverse routing
discussion
used to be called routing header, but the name was changed
because that was not
its intened use. DB says it is really the decision of the
business. Ralph agrees.
Dale mentioned that v1.1 of CPPA will have deliveryChannels
specified for
the MSH services
vote
against:
Colleen Evans
abstain:
none
agree:
Dan Weinreb
Ralph Berwanger
Bruce Pedretti
Chris Ferris
David Burdett
David Fischer
Doug Bunting
Brian Gibb
Brad Lund
Iwasa
Dale Moberg
Hima
Arvola Chan
motion passes
- motion to remove DeliveryReceipt raised by Chris, David Fischer seconds
discussion: Doug argued that DR and Ack are essentially identical in
their
use and semantic behavior.
vote
against:
none
abstain:
none
agree:
Dan Weinreb
Ralph Berwanger
Colleen Evans
Bruce Pedretti
Chris Ferris
David Burdett
David Fischer
Doug Bunting
Brian Gibb
Brad Lund
Iwasa
Dale Moberg
Hima
Arvola Chan
motion passes
- discusion of syncReply attribute. really only needed when there are
intermediaries.
Chris suggests that creating a new element SyncReply with
actor="next" would
really be needed. Doug agrees. Need to target next SOAP node, not
just next
MSH node.
- motion to remove syncReply from everywhere raised by Brad Lund, David
Fischer
seconds
discussion: Ian asks, does this mean that there is no way to request
that the
connection be held open. Dale says that this is up to the
configuration of
the two endpoints to work out. Doug restates Chris' apparent
proposal for
a SyncReply element replacing Via (that only has syncReply
attribute now
anyway).
Chris offers friendly amendment to Brad's motion to add SyncReply
SOAP extension
element targetted at actor=next with mustUnderstand.
vote
abstain:
none
against:
none
agree:
Dan Weinreb
Ralph Berwanger
Colleen Evans
Bruce Pedretti
Chris Ferris
David Burdett
David Fischer
Doug Bunting
Brian Gibb
Brad Lund
Iwasa
Dale Moberg
Hima
Arvola Chan
motion passes
- motion to remove Via raised by David F, Chris seconds
vote
against:
David Burdett
abstain:
none
agree:
Dan Weinreb
Ralph Berwanger
Colleen Evans
Bruce Pedretti
Chris Ferris
David Fischer
Doug Bunting
Brian Gibb
Brad Lund
Iwasa
Dale Moberg
Hima
Arvola Chan
motion passes
YALDAWONTIAC (yet another lengthy discussion about whether or not there
is a CPA)
Ian asks everyone to consider the notion that the ebXML MSH does not
support
spontaneous unnegotiated e-commerce
lunch/break
Ian relinquishes chair to Brian Gibb
Brian accepts chair
motion raised by Ian - limit scope of v1.1 to pre-existing trade
agreements (eg. CPA), Chris seconds
discussion:
Brian, so what? how is this actionable? not clear that this motion
accomplishes. too general
and not specific enough. Ralph hole in the spec because we don't say
how to address
conflicts between message and "CPA". David, should be able to send a
message to
somebody without any prior agreement. Ralph, thinks that most
businesses do operate
under an agreement. Brian agrees that is his experience. David; what
happens when the
messages need to be changed? how is this handled? is the
contract/agreement renegotiated?
vote
against:
David Burdett
David Fischer
Hima
abstain:
Iwasa
agree:
Dan Weinreb
Ian Jones
Ralph Berwanger
Colleen Evans
Bruce Pedretti
Chris Ferris
Doug Bunting
Brian Gibb
Brad Lund
Dale Moberg
Arvola Chan
motion carries
motion by Ian: add wording to section 1.1.4 strong recommendation to
read and understand CPPA specification and its implications on
implementation, Dale seconds
discussion: David; you need to have information equivalent to what
is available in CPA. Colleen, calls out line 418
in v1.08 which seems to say this already. Ian; still need the strong
recommendation...
vote
against:
abstain:
Brad Lund
Doug Bunting
David Burdett
Iwasa
David Fischer
Hima
agree:
Dan Weinreb
Ian Jones
Colleen Evans
Bruce Pedretti
Chris Ferris
Dale Moberg
Arvola Chan
Ralph Berwanger
motion carries
motion raised by Ian; In section 1.1.4 add wording for an assumption
that a pre-existing trading relationship
and agreement exists between the two parties, Dan seconds.
discussion:
Colleen; we already have wording in the con-ops section (~line
415 in section 1.2.3), should be
sufficient. Dale agrees. Chris agrees. Doug; this conflicts with
line 399. Others think it consistent.
Doug; why is this mentioned twice? Ralph; David B, section 1.2
is normative in the spec, right?
so as normative text, we really don't need to make this change
to caveats and assumptions, do we?
vote
against:
Ralph Berwanger
Colleen Evans
Bruce Pedretti
Chris Ferris
David Burdett
Doug Bunting
Brian Gibb
Brad Lund
Iwasa
Dale Moberg
Arvola Chan
abstain:
Hima
David Fischer
agree:
Ian Jones
Dan Weinreb
motion does not pass
Ian; why were we arguing, we never changed anything. David F; because we
made an agreement
in the spring not to require a CPA.
Brian relinquishes chair to Ian
Ian accepts chair
Ian; what do we want to do about duplicateElimination/idempotency? Is
this an issue?
Dale; yes, it is for CPPA. need to add duplicate elimination. Doug; it
is up to the higher levels
of the application to determine whether the receiving MSH should filter
out duplicates, or whether
it can treat the (duplicate) message in an idempotent manner. Placing
duplicateElimination
in the header is misplaced. It is also something that does not need to
be directly reflected
in the CPA. Dale; detecting duplicates has to be agreed by both sender
and receiver.
DavidB; so you're saying that idempotency is related to the service and
action? DavidF
wonders: say I'm sending a bunch of EDI messages to the same service and
action? Would
it change on a message by message basis? DavidF thinks Chris is right!
for a given service
and action, duplicate elimination is not going to change, put it in the CPA.
motion by Doug; remove QOSInfo and move DE attribute as a parameter in
the section
that discusses parameters that are necessary to configure an MSH. Chris
seconds.
discussion:
Ralph; wants to raise what was agreed in the Dallas meeting about
what we agreed
to do for 1.1. If we don't draw a line in the sand, then 1.1 may as
well be 2.0. Frustrated
that we're doing something to QOS or another of the elements. David
F asks, yeah, why are
we making this change. Dan; because there is an inconsistency (bug)
in the spec because
we don't say to an implementer what to do when DE says one thing and
the CPA says another!
vote
against:
bruce, ralph, colleen, david, david, iwasa, hima, brad, brian
abstain:
none
agree:
doug, dale, arvola, chris, dan
motion does not pass
motion raised by Ralph; we agree that one or the other (message header
or CPA) takes precedence.
Colleen seconds. David F thirds.
DavidF offers friendly amendment that the CPA takes precedence.
Colleen offers friendly
amendment to amendment CPA or its equivalent.
revised motion: we agree that the CPA or its equivalent takes
precedence over the messageheader.
discussion:
a bunch of side discussions.
against:
dan, david, david, ralph, colleen, Ian (tie-break)
abstain:
brad, iwasa, doug, brian
agree:
dale, arvola, hima, chris, bruce
motion does not pass
motion raised by DB; information in the header actually overrides info
in the CPA.
discussion:
Ralph; seems like we're trying to engineer this on the fly. The
longer we chase this
rabbit around the tree, the more likely we'll make an incorrect
decision. Ralph wants
time to think about this, suggest we table 'til morning.
meeting adjurned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC