OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ebxml-msg] RE: pending issues

Title: RE: [ebxml-msg] RE: pending issues


-----Original Message-----
From: Pete Wenzel [mailto:pete.wenzel@Sun.COM]
Sent: Tuesday, March 07, 2006 3:28 PM
To: Jacques Durand
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] RE: pending issues

I'm putting the finishing touches on WD 10, for publication later
today, but have several concerns:

A. Issue #7: It is not clear why mustUnderstand has been lumped in
   with actor/role, as they are unrelated; mention of mustUnderstand
   remains necessary.  I propose to take your (Jacques') suggestion
   from Jan 10 email:

   > Section on SOAP mustUnderstand reads too much like a
   > tutorial.  Reword it by simply stating that this attribute is
   > required on eb:Messaging header, and must have value "1".

<JD> The suggestion above is already implemented in 5.2 (eb:Messaging container element section in Packaging). So we can indeed remove the little "tutorial" section.

B. Issue #18 (SOAP Binding, Section 11-Old vs. Section 12-New).
   Griping about standards processes (or lack thereof) and
   rationalization of our direction in Section 12 (lines 3533-3554 in
   WD 08) is unnecessary.  We need to specify, clearly and concisely,
   exactly what we expect implementers to do, not why.  Propose to
   strike these lines.

<JD> We Fujitsu agree - these llines were more for addressing previous comments . Maybe we could say something like: "Although a SOAP 1.2 version of SWA has not been formally submitted to W3C, it appears that most SOAP products have anticipated that usage, and after investigation, it appears that they have done so in a consistent, interoperable way. This specification is acknowledging these de-facto upgrades of SWA, which are summarized below."

   The proposal to remove Section 11 would leave us with no normative
   statements as to proper use of HTTP(S)/SMTP.  (Sections 12.2 & 12.3
   contain only examples, not specifications of the bindings.)  If the
   argument is that [SOAP 1.1 + WS-I BP (+ SwA)] or [SOAP 1.2 +
   Adjuncts (+ SwA)], in addition to the HTTP, SMTP and related RFCs
   contain all the detail necessary, then we should make such a

<JD> According to the author (Hamid) who is also developer, the Sections in 12 have all necessary information for SMTP binding as well as HTTP. Except for the use of SOAPAction header that is required and could be reminded more explicitly (outside example). All useful statements are already added prior to the examples. All previous statements (section 11) are redundant with other referred specs (SWA, SOAP, RFCs.) and do not introduce any ebMS-specific profiling.

Still skeptical of the claim that there aren't any
   options in these specs that we need to address in ebMS, and that
   all of the detailed guidance presented in Section 11 should be

   The correct media type for a SOAP 1.2 document is
   "application/soap+xml"; not "text/xml", as it is for SOAP 1.1.

<JD> OK, need be fixed.

   (Minor) The HTTP & SMTP examples should contain all required
   headers, not just the ebMS-specific ones, to avoid confusion.

<JD> the examples only illustrate binding info. HTTP headers could be added indeed. SMTP headers seem to be complete?

and finally,

C. Issue #10 (Security Section): I will capture Ric's March 02
   preliminary list of security requirements, but it is unclear at the
   moment exactly what the effect will be on the text and examples
   in Sections 6.2-6.7.

<JD> Hamid says: bullet list useful, but examples - unlike for ebMS packaging - have little value - unnecessary for developing. Such headers will be generated by security package.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]