ebXML CPPA Technical Committee Teleconference
(Non Voting)
January 3, 2002
Attendees
Selim Aissi
Arvola Chan
Jamie Clark
Brian Hayes
Neelakantan Kartha
Pallavi Malu
Dale Moberg
Himagiri Mukkamala
Peter Ogden
Marty Sachs
David Smiley
Tony Weida
Minutes
Dale suggested dividing up the issues list numerically among team members who will
participate in the F2F and asking each participant to be responsible for identifying
which of their assigned issues may require more discussion or work. In preparation, Tony offered to produce reports listing issues targeted for version 1.1 and issues not currently targeted for a specific version. He and Dale will discuss the reports offline then distribute them to the list.
Regarding the disposition of Arvola's draft document on how to use CPA parameters with the messaging service, Dale reported that OASIS has no mechanism for technical committees to jointly publish a specification. He felt that the effort to put such a mechanism in place would probably not be worthwhile. Dale noted that our team could publish it individually, and some feedback he's received from other teams suggests that wouldn't be a bad thing. Ian Jones from MSG hasn't indicated that he's actively pursuing publication of the document. It's still possible that the document may fall under the IIC team's
purview.
We discussed Arvola's question about what to do from an implementation perspective,
considering various APIs involved, when SyncReply with a value of both is combined with
an MSG acknowledgement request, so that the response, business signals and MSH signals all come back on the same connection, and an ack to the response is to go back the other way. Dale suggested referring the issue to the implementation group (IIC) and Arvola agreed. Dale will draft a description of the issue and send it to Arvola; when they reach agreement, it will be sent to IIC on behalf of our team.
Arvola mentioned that MSG version 1.092 has been released. He identified an additional interlock issue with CPPA. After discussion, we agreed to remove the following statement from the 1.1 CPP/A spec to better conform with MSG:
'"If the delivery channel identifies a transport protocol that has no synchronous
capabilities (such as SMTP) and the Characteristics element has a
syncReplyMode attribute with a value other than "none", a response SHALL contain the same content as if the transport protocol did support synchronous responses."
We further agreed to add clarification language to the effect that a syncReplyMode other than "none" SHALL NOT be used when the delivery channel uses an asynchronous
communication protocol.
Arvola asked whether we might want to relax the "SHALL NOT" in later versions
and suggested that syncReplyMode has packaging-related notions too; he agreed with Marty
that for version 2.0 we should separate those notions.
Jamie questioned a change in the version 1.01 draft, where this passage was deleted:
"Each Party SHALL have a default delivery channel for each
Process-Specification document referenced in the CPA. For each
Process-Specification document, the default delivery channel for each Party is the delivery channel that is indicated by the channeled attribute in the
highest-preference ServiceBinding element that references that
Process-Specification document."
... and replaced with the following passage:
"Each Party SHALL have a default delivery
channel for the delivery of standalone Message
Service Handler level signals like (Reliable Messaging)
Acknowledgments, Errors, StatusRequest, StatusResponse,
etc."
In particular, he wanted to know whether the default delivery channel, given the new
passage, no longer covers business signals. Arvola thought they'd be considered
business level messages, with a corresponding service and action. In the case of
multiple payloads in a message, each with its own service and action, Dale noted the
question of which should be mentioned in the SOAP header. Dale thought there was a
(stated) rule that the order of precedence was first the business response service and
action, then the business signal service and action, then the messaging service (SOAP)
ack. Arvola noted that the MSG team has defined a specific service and action to be
used for the MSH signal on its own. Dale thought the priorities might be mentioned in
the messaging spec, but encouraged Jamie to remind us if he still feels we need to
address the matter in our spec.
Tony described a proposed schedule for draft versions of the specifications leading up to
the San Francisco F2F. For details see his email:
http://lists.oasis-open.org/archives/ebxml-cppa/200201/msg00018.html
Peter O. would like to submit some security-related changes by Monday, but needs feedback
first. For details, see his note and the attachment:
http://lists.oasis-open.org/archives/ebxml-cppa/200201/msg00019.html
As a purely editorial matter concerning digital signatures, Jamie pointed out that the
spec
- Sometimes talks about digital signatures as a generic mechanism, and seems indifferent
about whether XML DSIG or some alternative is used
- Sometimes just says "digitally signed" but probably means only XML DSIG
- Sometimes says [words to the effect of] "you're going to use XML DSIG, by
God"
He asked what the intent of the spec really is. Dale thought the intent was for XML DSIG
to be the main signature technique when working WRT ebXMLBinding, but independently
signed payloads are allowed as part of packaging. Jamie committed to noting the passages that he finds in need of improvement.
Tony reported on his correspondence about copyright statements with Karl Best. Karl
suggested using the OASIS copyright statement on version 1.1, along with a note that it
was derived from version 1.0 which was jointly copyrighted by UN/CEFACT and OASIS. Jamie thought that was about right. He volunteered to craft specific language and send it to
Tony. Arvola suggested looking at the MSG spec. Marty said that MSG v. 1.092 has the
joint copyright statement.
Next Meeting
There will be another teleconference next week on January 10.
Metadata
Please send additions and corrections to Tony Weida
(rweida@hotmail.com).
Respectfully submitted,
Tony Weida
|
