issues for MS v0.73

[Christopher Ferris <chris.ferris@east.sun.com>]

All, 

Just got back from vacation. I notice that I missed the deadline
but most of these comments can be taken up for discussion in the
review phase. Of course, I haven't quite finished with my review,
but these will have to do for now.

Here are my notes/issues which relate to v0.73 of the new combined
spec (Messaging Service). Some are from POC feedback and should be
incorporated before we release for the review cycle. Some are editorial
and should be addressed. I have labeled these as *issues*.

Others, which I will note as *defered* should be considered as defered until
the review cycle unless there is consensus that the changes be made
by the group in the thursday con-call or via email.

Cheers,

Chris

defered - Introduction 
	this section should reflect the revised nature of the document.
	the Messaging Service (ebXML-MS) specification will define the
	whole service, not just the structure of the messages. I like
	Rik's idea of having 'parts' or 'sections', but another consideration
	would be to wait for the revised format and as a group, decide how
	a 'service' can be mapped.

defered - Purpose and Scope
	same comment as above. needs to be refactored.

defered - line 150
	Do we want to rename this section? I would think that a related and
	relevant ebXML specification would be the one to be developed
	by the newly formed Trading Partnet PT (TPA). Granted, we aren't
	authoring that document, but it is strongly related and this should
	be acknowledged IMHO.

defered - line 168
	this needs to be a little less terse. Something like:
		Message Headers - a specification of the structure
		and composition of the information necessary to an
		ebXML Messaging Service to successfully process an
		ebXML compliant Message.

defered - line 169
	do we still need this?

issue - line 174 under General Conventions
	XML tags are case sensitive. The statement here derives from the
	packaging specification which discusses MIME headers and attribues
	which is expressly case insensitive. I think that this needs some
	serious clarification before the document is released.

issue - line 180
	this seems to be an unintended carry-over from the merge and should be removed.		

defered - line 182
	do we want to define the term and concept of an ebXML Message? I would
	think that we would;-) I think that we should have a consistent mechanism
	for identifying all ebXML Glossary defined terms (italics?) and that
	ebXML Message should be one of these terms.

issue - line 184/185
	remove the phrase 'for example'. We have concluded that it IS MIME
	multipart/related
	Suggested phrasing:
		a transport independent Message Envelope which is a MIME
		multipart/related container which encapsulates the two
		principal parts of an ebXML Message:

issue - line 187
	please change to 'a single Payload Container...' for clarity.

issue - line 211
	I think that we need to resolve this issue before we release the
	document for review. It is too much of a substantial change to
	leave out. I think that Dick owns this, correct?

issue - line 219
	please change: 'Implementers of software to process ebXML messages MUST ...'
	to: 'Implementers of an ebXML Messaging Service MUST ...'
	I also think that the close of this sentence could be made more clear.

editorial - line 222
	if Message Envelope is a Glossary defined term, it should be capitalized
	and italicized, no? Also, message should be ebXML Message and similarly
	italicized.

editorial - line 229
	I assume that the appendicies will be cross referenced with their
	references. Please review to ensure that any references are updated
	accordingly before publishing.

issue - line 230
	references four (4) attributes, yet only two (1 and 4) are listed.
	please fix this.

issue - lines 234-243
	are these attributes mandatory? Should we use MUST or SHALL to
	make this clear? I would think that both attributes MUST be present.
	Type to clearly and unambiguously identify the message as an ebXML
	Message and the other (boundary) to demark the boundaries of the
	MIME multipart/related body parts.

editorial - line 247
	is Content-Length a mandatory header? If so, this should be made
	explicit. If not, then the header should be expressly identified
	as advisory. I would think that it would be useful to have this
	always present.









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