RE: comments from doug bunting on v0.98b

["Burdett, David" <david.burdett@commerceone.com>]

Some comments on a few of Doug's Comments ...

>>editorial - lines 338 and 340 append "may be omitted" to each<<
Only the Message header is REQUIRED (which is clearly stated), all the
others may be omitted in some circumstances. Suggest no change.

>>CBF: minor technical - line 489 - XMLSchema now uses 'dateTime' instead of
'timeInstant'
	in PR draft. The problem we face is that most tools support the CR
which used
	'timeInstant'! We are faced with a version skew problem w/r/t
XMLSchema!<<
This is a tough one. On balance I think we should go with the PR and allow
non-normative variations of the schema that conform to the CR datatypes as
in the instance I don't think it matters. We also need to specify in the
Schema defintion, which version of XML Schema is being used. I also wonder
if there will be more changes in the actual recommendation !!

>>minor technical - line 910/911 - why not? remove this constraint to avoid 
	confusion<<
Because software that is displaying the error, might want to follow the
error to display the source of the problem. If this is pointing into to
payload it could be hard to **always**do.

>>editorial/minor technical - lines 937-941 - remove this as implementations
	may choose to do as they see fit. <<
It's only "RECOMMENDED" not a "MUST" this means that implementations can do
as they see fit.

>>minor technical - line 985 - why do we need id attribute on Manifest?<<
Earlier we decided to put id's attributes on several elements to make it
easier to point to errors. However we have not done is use id attributes
consistently. The real question is do we want id attributes on elements or
not. Whatever we do we should be consistent. Thoughts?

>>major technical - line 1117 - Acknowledgment element needs #wildcard to
put Digest
	value. (CBF: Either that or an explicit reference to
ds:DigestValue)<<
If we include ds:DigestValue, how do you know how to calculate it. To do it
properly requires that the message over which the digest is being generated
is canonicalized and transformed along the lines of XML Dsig. Where is the
information on this? I think if you want absolute proof of receipt, then you
need to both sign the message being sent and sign the acknowledgement. In
this case, you could require that the signature on the acknowledgement
contained a signature manifest reference to the original message being
signed. It also means that you don't need ds:DigestValue in the
Acknowledgement element. Thoughts?

>>major technical - suggest that we remove type and signed attribute from 
	Acknowledgment element. (CBF: this relates to issue I raised with BP
	as regards DeliveryReceipt. I also agree that signed attribute adds
no
	intrinsic value).<<
I agree that the signed attribute is not really required. On the type
attribute, we agreed on the teleconference call yesterday that we would
separate the two "types" of acknowledgement as a type of "acknowledgement"
was used for reliable messaging purposes, and a type of "delivery receipt"
was used for proof of delivery. We then recognized that the delivery receipt
might then need to be aligned with whatever the BP folks do.

>>CBF: major/minor technical - I recommend that mshTimeAccuracy be
eliminated. Its usefulness
	is suspect and it is not represented in CPA. Strike section 10.2.2
and the
	paragraph at lines 1374-1378<<
I agree that in many, many instances its usefulness will be limited as
people won't keep their clocks very accurately. However in other
circumstances it might be vital, for example on-line stock trading, when
there might be debate over when a transaction occurred. I suggest that we
add it to the CPA and leave it in the spec.

>>minor technical - line 1485-1496 - confusing mix of identifier and
location values
	for From and To! <<
I agree. This has arisen because we made trace header optional. If you a
doing a single hop, then the From is equivalent to the SenderURI, and the To
is equivalent to the ReceiverURI, however they are not if you are doing
multi-hop. The simpler solution would be to make the TraceHeader a required
element in every message and always use the sender/receiverURIs then it
works for both single and multi-hop equally well. The less optionality you
have, then the more interoperable the spec, IMO.

>>CBF/DB: editorial - lines 1508-1516 - suggested replacement text:
	1) The Sending MSH MUST resend the original message if an
Acknowledgment message
	has not been received within the time specified in the retryInterval
parameter
	and the MSH has attempted to redeliver the message fewer times than
are specified
	by the retries parameter.<<
Although this is simpler, it makes the timeout parameter redundant. I don't
have a problem with this although it will require several changes to the
spec and possibly the CPA. However if we do this change, I think we need to
tweak the text ever so slightly as follows:
	1) The Sending MSH MUST resend the original message if i) an
Acknowledgment message has not been received, ii) at least the time
specified in the retryInterval parameter has passed since the message was
last sent, and iii) the MSH has attempted to redeliver the message fewer
times than are specified by the retries parameter.<<

David

<SNIP>

Solution Strategy, Commerce One
4400 Rosewood Drive, Pleasanton, CA 94588, USA
Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704; Pager: +1 (888) 936
9599 
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com