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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: comments on v0.2 MS spec

Here are some comments/edits for the v0.2 MS spec
as we enter the final stage. Most are editorial in



Line	Category	Comment
----	--------	-------------------------
103	1		change "... that describes how to
			securely and reliably exchange ..."
			to "... that enables the secure
			and reliable exchange of ..."

111, general	
	1/2		we seem to use 'enveloping' and
			'packaging' interchangeably. I think
			that we should use a consistent
			term: 'packaging'. That is afterall
			the heading on section 3.

118	1		I think that we should omit the
			version of the Overview & Req'ts doc
			in the text and leave that to the
			reference section

121	2		do we want to add 'and emerging'?

122	2		replace the term "package" with

155/6	1		is this really a convention? I would
			have thought that a convention described
			treatment of the style of the document.
			this seems to reflect a feature of
			the specification

160	2/3		technically, the ebXML message is
			carried by a transport within the
			(optional) protocol specific 'envelope'.
			Thus, technically, the (optional)
			protocol specific envelope is
			NOT part of the ebXML Message.
			Suggest that line 160 be removed

164	1		replace 'optional' with 'zero or one'
			so as not to conflict or be confused
			with OPTIONAL as described in RFC2119

165	1		remove 'if payload is present'. This
			is redundant. 

166	1 		the document might benefit from a 
			BNF description of an ebXML message.

			ebxml-message = ebxml-message-envelope
			ebxml-message-envelope = 

168	1		replace 'Envelope' with 'Container'
			so as to be consistent with line 163

173	1		replace with:
			Normative communication protocol 
			bindings are defined in Appendix E

175	1/2		I think that this is where we should
			point out that MIME headers are case
			insensitive. e.g. 
			Content-Type is equivalent to

199	1		add period after '... of a body part'
			capitalize 'see'.

205/6	2		remove reference to version-less 

208/9	2		strike. If none are defined, we should
			simply omit this concept.

231	1/2		add 'Envelope' as the Header container
			is the first body part WITHIN the
			Envelope, not the first in the
			ebXML Message.

239	1		replace 'enhanced' with 'modified'

240	2		XML DSig may permit modifications
			to the Header document without violating
			the signature. Not sure if we
			want to point this out. Possibly, we 
			should omit this paragraph (239/242)
			in lieu of delivery of the Security
			spec draft.

244	1		change 'header identifies' to:
			'header uniquely identifies'

245	2		do we want to reference RFC 2392 here?

284	1		capitalize MUST NOT

287 	2		do we want to reference RFC 2392 and
			2557 here?

297	2		do we want to permit use of the
			Content-Location header as described
			in RFC 2557. If so, then the text
			should reflect that the Content-Location
			header MAY be present, etc.

311	1		is Content-Type value determined by
			the implementer? I would think that
			a more correct statement would be that
			it is determined by the application
			which creates the message.

336	1		replace 'comprised of' with 'MUST have'

338/9	2		we need to get closure on a namespace
			scheme for ebXML. I have sent email
			to ebxml-architecture for guidance.

343	1		replace 'communication' with 'Message 

345	1		add 'attribute' after MessageType

350	1		replace 'contains' with "MUST have"

356	1		strike this sentence. It is redundant
			of the previous sentence (with the
			suggested edit for line 350).

366	1		capitalize REQUIRED

369	2		do we want to reference RFC 2557
			to describe how CID may be used as
			a URI within the Manifest element?

374	2		there are three possible elements
			not two. Two are REQUIRED, one has a
			cardinality of zero or one.

374	1		capitalize REQUIRED

376	1		replace 'an optional' with 'zero or one'

377	2		is it a code? I would think that this
			might be misconstrued. It could be
			the value of the root element of
			an XML document, it could be a code
			from some context. It is also not
			clear to me that the "purpose" is
			necessarily conveyed. I might send
			a PurchaseOrder with the "purpose" of
			initiating a purchase agreement. I
			might also send it to revise a previous
			agreement. In either case, it is still	
			a PurchaseOrder. The purpose or intent
			is intended to be conveyed with the
			ServiceInterface and/or Action elements
			of the Header.

379	1		replace 2111 with 2392 which obsoletes

379	2		do we want to reference RFC 2557:
			MIME Encapsulation of Aggregate 
			Documents, such as HTML (MHTML). This
			would help in the understanding as
			to how this should be treated by
			a parser.

386	1		need an example which better
			reflects the recommended 
			<authority><local> scheme for 
			generating a globally unique id.
			Note that I could find no reference
			to this in RFC 2392 as suggested
			in some of our discussions. Perhaps
			I have the RFC # incorrect?

390	1		capitalize REQUIRED

	1		change 'ebXMLMessageHeader' to 

392	1		capitalize REQUIRED

450	1		an example MessageId would be useful

454	1		replace 'an optional' with 'a'

510	1		add the following to list of

			Philippe DeSmedt - Viquity
			Gordon van Huizen - Progress
			Jim Hughes - Fujitsu
			Nicholas Kassem - Sun
			Nikola Stojanovic - ebXML Architecture Liason
			Marc Breissinger - webMethods
			Joe Lapp - webMethods

appologies if I've omitted anyone else who feels that
they have contributed. Please feel free to let me, Rik
or David know who you are and we will add your name to
the list of contributors.

                               Christopher Ferris
    _/_/_/_/ _/    _/ _/    _/ Enterprise Architect - EMA 
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063      
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC