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: MAJOR TECNICAL comments on v0.98


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.




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 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:

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


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


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

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


4 - line 1502 - in this same vein, I would propose that the Service for
	the standalone Acknowledgment be made:

	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

	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

	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.

[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