[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