MAJOR TECNICAL comments on v0.98

[christopher ferris <chris.ferris@east.sun.com>]

All,

Here are my MAJOR TECNICAL comments on v0.98. Again, I wish to express my
sincere thanks to the hard work and dedication of the editing
team. They did an outstanding job!

I have organized my comments by type (Editorial, Minor and Major
Technical) in separate emails for convenience. I have also listed 
the section and line number for ease of identifying the change location 
in the context of subsequent revisions.

I have also numbered each comment for ease of reference in any discussion.

Cheers,

Chris

MAJOR TECHNICAL

section 8.5.8

1 - line 574 - Requiring that SequenceNumber ONLY be present with
	OnceAndOnlyOnce and Guaranteed seems to me to be a limitation
	that could constrain an implementation from using SequenceNumber
	as a means of enforcing RM when the SequenceNumber is
	applied by the MSH and NOT by the Application (From Party).
	
	I would much prefer that SequenceNumber ONLY be present
	when OnceAndOnlyOnce is specified, and that the semantics
	of messageOrderSemantics MAY be used to instruct the receiving
	MSH to deliver the messages in the order in which the Application
	determines by virtue of the SequenceNumber.

section 9

2 - line 1209 - I would like to porpose that the Message Service Handler Services
	NOT be REQUIRED of an implementation (*). This would involve changing MUST to 
	MAY. Interoperability can be handled with returning a SOAP:Fault
	with MustUnderstand as the fault code if an implementation of the MSH
	does NOT support the service requested.

	(*) NOTE: that the "Acknowledgment" and "Error" services should probably be defined in 
	section 9 as they really are just another "service" of the MSH. Possibly,
	we could/should relocate section 10.3.1.3 to section 9 and then have
	a backwards reference to it in section 10.3 somewhere. Section 11.5 
	or some rewording of it should also be included in section 9 and then 11.5 could
	backwards reference section 9.x as well. THESE services MUST be supported
	by an MSH, but the others should NOT be REQUIRED, IMHO.

3 - line 1209+ - I would also propose that the Service and Action values be a) made
	consistent and b) expressed as URIs rather than as URLs so that
	they are not mistaken for endpoints and/or namespaces. To be honest,
	the length of the URI also troubles me. What I propose below is half
	the length and still provides us with the semantics we need.

	Status Request Service:

	From:
	
	Service: http://www.ebxml.org/namespaces/messageService/MessageStatus
	Action: Request and Response

	To:

	Service: uri:www.ebxml.org/messageService/
	Action: StatusRequest and StatusResponse
	
	Ping/Pong Service

	From:

	Service: http://www.ebxml.org/namespaces/messageService/MSHStatus
	Action: Ping and Pong

	To:
	Service: uri:www.ebxml.org/messageService/
	Action: Ping and Pong

section 10.3.1.3

4 - line 1502 - in this same vein, I would propose that the Service for
	the standalone Acknowledgment be made:
	
		uri:www.ebxml.org/messageService

	preserving the Action of 'Acknowledgment'

5 - line 1504-1507 - the REQUIRED use of SenderURI and ReceiverURI for population
	of the To and From PartyId values in an Acknowledgment message is incompatible
	with the optionality of the TraceHeaderList element unless there are
	multiple hops involved. It is also inconsistent with the new Via element
	which provides for the ability to communicate via the Via/CPAId element
	a set of virtual CPA parameters for the MSH2MSH exchange that could inform
	the receiving MSH as to how to populate the To/From PartyId for an acknowledgment
	message. 

	I would therefore propose that these lines be striken and that we leave
	the population of the To and From PartyId an implementation decision OR
	that we suggest that the responding MSH MAY use these values, if present
	to populate the To/From PartyId OR, it may simply exchange the values
	of the message received (To->From From->To) OR that it may use information
	that is available to it by virtue of the Via/CPAId element to populate the
	To and From PartyId.

section 11.5

6 - line 1642+ - In the same vein of modifying the Service identifier, the
	Error service should be made the same URI as I have proposed for the others
	above: 
		uri:www.ebxml.org/messageService

	preserving the Action of 'MessageError'.

7 - line 1642+ - Note that the Service and Action for the Error service MUST
	only be used when the highestSeverity="Error". This needs to be said somewhere
	in section 11.5.