[ebxml-msg] Status of Messaging spec signals

[Rik Drummond <rvd2@drummondgroup.com>]

ian, we are doing the interoperability test for ebXML ms. We need to
ensure that the signals are correctly aligned  with respect to the ms,
cpa and bpss spec. if I send these to you can you have some one look and
them and give us feedback. I am also sending these to dale moberg for
cpa and paul for b pss..... thanks, rik



-----Original Message-----
From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com] 
Sent: Friday, August 02, 2002 8:40 AM
To: db134722@iplanet.com; ebxml-msg@lists.oasis-open.org
Cc: phil.griffin@asn-1.com
Subject: RE: [ebxml-msg] Status of Messaging spec vote

Doug,

	thanks for this.  I have also been trying to clarify Phil's
comment
with him and I am awaiting a reply.

	We now need to hold a "meeting" to agree on the disposition of
Phil's comment.  I would like to do this with Phil being present so that
we
can all understand his concern and ensure we address the comment in an
informed and reasonable manner. 

Ian Jones
Chair OASIS ebXML Messaging Services TC 

Email: ian.c.jones@bt.com 



-----Original Message-----
From: Doug Bunting [mailto:db134722@iplanet.com]
Sent: 02 August 2002 00:53
To: ebxml-msg@lists.oasis-open.org; phil.griffin@asn-1.com
Subject: Re: [ebxml-msg] Status of Messaging spec vote


All,

We at Sun previously contacted Phil Griffin to ask for a clarification
of
his comment.  Quoting from an email in that discussion:

| I'm not entirely certain ebXML Messaging prevents use of ASN.1 in
| the ways Phil would like.  The specification is entirely payload
| agnostic and goes so far as to recommend the SOAP Body not be used
| to contain the application content.  No requirement for an XML
| Schema description of the payload or payloads exists.  In this
| respect, the existing specification remains schema independent.
|
| If he would like to utilize ASN.1 to validate, encode and sign the
| message header itself, he's correct that he's out of luck.  We had
| to choose a single technology because of the need to identify in
| the message its relevant schema.  I don't understand a way to make
| this aspect of ebXML Messaging schema independent.  Yes, we could
| have defined the concepts at a higher level and bound them to SOAP
| but the additional layer wouldn't have helped with
| interoperability concerns.  If this is Phil's primary area of
| concern, he should vote "no" on the SOAP 1.2 specification at the
| W3C.

Phil, would you care to comment further for the benefit of this group?
I
may not have been clear in my comments above: ebXML Messaging defines a
wire protocol for carrying some semantic / descriptive information
between
two systems.  That wire protocol is schema dependent to the extent it
leverages the SOAP protocol.  That extent does not cover the associated
business documents or (more generically) payload content.  ebXML
Messaging
is completely payload agnostic and schema independent for those
payloads.

thanx,
    doug

"Karl F. Best" wrote:

> Messaging TC:
>
> Voting for consideration of the ebXML Messaging Committee
> Specification as an OASIS Standard ended yesterday. The vote did reach
> quorum, and a vast majority of votes were affirmative.
>
> There was, however, one negative vote. (Please see
> http://lists.oasis-open.org/archives/tc-voting/200207/msg00003.html)
> As defined by the OASIS TC Process
> (http://www.oasis-open.org/committees/process.shtml#sec2) if there are
> any negative votes the TC must decide how to handle this:
>
> "...if negative votes amounting to less than 10 percent of the voting
> membership have been cast, the negative votes and accompanying
> comments, if any, shall be forwarded to the originating TC for
> consideration. After notification of the results, the TC shall have 30
> days to take one of the following actions by resolution: (x) request
> OASIS to approve the specification as submitted despite the negative
> votes, or (y) withdraw the submission entirely, or (z) submit an
> amended specification, in which case the amended submission shall be
> considered as if it were a new submission, except that information
> regarding previous votes and any disposition of comments received in
> previous votes shall accompany the amended submission."
>
> The TC must now decide, within 30 days, which of these options to
> select.
>
> </karl>
> =================================================================
> Karl F. Best
> OASIS - Director, Technical Operations
> +1 978.667.5115 x206
> karl.best@oasis-open.org  http://www.oasis-open.org
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

Attachment: Rik Drummond (rvd2@drummondgroup.com).vcf
Description: text/vcard