RE: [ebxml-msg] Meeting Agenda

["Zimek, Sinisa" <sinisa.zimek@sap.com>]

Ian,

I won't be able to attend the upcoming f2f meeting in Miami due to travel conflict with an other commitment.

As announced, attached please find SAP's feedback on the 2.0 version of ebxml messaging as an input for the meeting. If there is any clarification required please let me know. Otherwise I'm looking forward to have them including in the next spec release.

Kind regards,

> Sinisa Zimek
> Director Technology Architecture & Standards
> SAP Labs, Inc.
> 
> 3475 Deer Creek Road
> Palo Alto, CA 94304
> T (650) 849-2647
> F (561) 258-8588
> E sinisa.zimek@sap.com
> www.saplabs.com


-----Original Message-----
From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com]
Sent: Friday, October 04, 2002 12:40 
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Meeting Agenda


Team,

	I have updated our web pages with the agenda for the meeting.  It is
the same as the one I posted earlier this week.  I have not had any
volunteers to host any conference call facilities yet, so I can not confirm
if we will be able to do anything.  If any one wants to talk I will
contactable  via my office number anytime until Monday night.

	See those of you coming to the meeting next week, have a great
weekend.

Ian Jones
Chair OASIS ebXML Messaging Services TC 

Tel:   +44 (0)29 2072 4063
Fax:   +44 (0)29 2072 4137  
Email: ian.c.jones@bt.com 



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

--- Begin Message ---

• To:
• Date: Sat, 5 Oct 2002 00:01:20 +0200

Feedback Summary - ebXML MSG 2.0:

1. single part text/xml soap
This version 2 added the following lines to support an ebXML message in a normal text/xml MIME message when there is no payload. However, this paragraph is very much hidden in the spec because the rest of the spec talks only about multipart MIME. This paragraph should be explicitly referenced from section 2.1. to be more visible.

512 Implementations MUST support non-multipart messages, which may occur when there are no ebXML 
513 payloads. An ebXML message with no payload may be sent either as a plain SOAP message or as a 
514 [SOAPAttach] multipart message with only one body part. 


2. content type of soap
The spec says that content type text/xml must be used for the soap part, as in lines 520-521. But in lines 573-578, there is a note that talks about the editors' and some others' opinion on this negative decision.  In fact, I agree with this opinion, however, I believe that including such an example and statement would just confuse people. If the spec means that conformant implementations MUST use 'text/xml', as stated in lines 520-521, there should be no example using 'application/xml' in the spec and the note paragraph in lines 573-578 should be written differently.

520 The MIME Content-Type header for the Header Container MUST have the value "text/xml" in 
521 accordance with the [SOAP] specification. The Content-Type header MAY contain a "charset" 

573 Note: It might be noticed the content-type used in the preceding example (application/XML) is different than the content-574 type in the example SOAP envelope in section 2.1.2 above (text/XML). The SOAP 1.1 specification states 
575 the content-type used for the SOAP envelope MUST be 'text/xml'. However, many MIME experts disagree with 
576 the choice of the primary media type designation of 'text/*' for XML documents as most XML is not "human 
577 readable" in the sense the MIME designation of 'text' was meant to infer. They believe XML documents should be 
578 classified as 'application/XML'. 


3. namespace of ebxml message header extensions
The spec chose a namespace ending in suffix .xsd. This strongly implies that the schema document (in particular a XSD schema) is available at this namespace and does not leave a room for providing something else such as other schema description, a human readable document, etc. So, I think this is a wrong decision.

616 The namespace declaration for the ebXML SOAP Envelope extensions (xmlns pseudo attribute) (see 
617 [XMLNS]) has a REQUIRED value of: 
618 http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd 


4. inclusion of schemaLocation
Is it allowed to give a different schemaLocation that is structurally identical to the original ebxml schema? Or more interesting question is, is it allowed to give an extension of the original schema? If not, the spec should say, schemaLocation, if given, must take the fixed value of the ebxml schema locaiton URL.

626 All ebXML MSH implementations are strongly RECOMMENDED to include the XMLSchema-instance 
627 namespace qualified schemaLocation attribute in the SOAP Envelope element to indicate to validating 
628 parsers a location of the schema document that should be used to validate the document. Failure to 


5. optionality of Manifest
The lines 683-384 say, withouit any condition, the Manifest element MAY be omitted. This should be qualified with "if no payloads are included".  Simply omitting the Manifest element can lead to discaring the payloads, as stated in line 991.

683*Manifest - an element pointing to any data present either in the Payload Container(s) or elsewhere, e.g. on 
684 the web. This element MAY be omitted. 

991 Note: If a payload exists, which is not referenced by the Manifest, that payload SHOULD be discarded. 


6. CPAId consistency
I don't think this part has improved in clarity in comparison to the version 1.0. It still does not seem to state the responsibility of the receiving MSH clearly enough so that they can interoperate.

818 If a receiver determines that a message is in conflict with the CPA, the appropriate handling of this conflict 
819 is undefined by this specification. Therefore, senders SHOULD NOT generate such messages unless
820 they have prior knowledge of the receiver's capability to deal with this conflict. 
821 If a Receiving MSH detects an inconsistency, then it MUST report it with an errorCode of Inconsistent 
822 and a severity of Error. If the CPAId is not recognized, then it MUST report it with an errorCode of 
823 NotRecognized and a severity of Error. 

7. Timestamp omitting 'Z'
The lines 882-886 say the dateTime instance given in the Timesamp element must be given in UTC, but its representation does not necesarrily require the UTC indicator  suffix 'Z'. This may cause a problem if a parsing code is generated from the schema and this code assumes XML Schema's interpretation of dateTime, where Z means UTC and nothing means local time.

884 The REQUIRED Timestamp is a value representing the time that the message header was created 
885 conforming to a dateTime [XMLSchema] and MUST be expressed as UTC. Indicating UTC in the 
886 Timestamp element by including the 'Z' identifier is optional. 


8. syncReply = true under ackRequested
Since the Acknowledgement element provides an explicit receipt information (e.g., with timestamp, authenticated signature, etc) of the message, it is quite natural to think that a synchrounous request may request an acknowledgement receipt. In fact, the spec does not prohibit this use. However, it does not specify if this acknowledgement element must be only returned together in the synchrnous response message or can be returned in another separate acknowledgement message. The spec needs to clarify this issue by prohibitting ackRequested for the synchrouns case, requiring the acknowledgement in the synchronous case to be returned in the synchrounous response, or allowing the aknowledgement  in the synchronous case to be returned separately.


Sinisa Zimek
Director Technology Architecture & Standards
SAP Labs, Inc.

3475 Deer Creek Road
Palo Alto, CA 94304
T (650) 849-2647
F (561) 258-8588
E sinisa.zimek@sap.com
www.saplabs.com

--- End Message ---