RE: comments from doug bunting on v0.98b

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

Chris

Comments marked with <DB></DB>

Best wishes

David

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Friday, April 06, 2001 12:17 PM
To: Burdett, David
Cc: ebXML Transport (E-mail); Doug Bunting
Subject: Re: comments from doug bunting on v0.98b


Comments cubed below.

Cheers,

Chris

"Burdett, David" wrote:
> 
> 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.

I think that the change is warranted for clarity and consistency.

<DB>OK. I re-read the whole section and noticed that "may be omitted" is
present on TraceHeaderList. Objection withdrawn</DB>

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

Let us hope not. I agree that we should probably issue one normative
version (that conforms to PR/REC) and one non-normative that conforms
to CR and most tool support. If we include (as I believe is suggested
in Doug's comments and seconded by my investigation of schema issues
of late) xsi:schemaLocation in our elements, then the issue of which schema
a particular instance document conforms becomes moot. The actual form of the
data contained in these modified type names is the same in any case.

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

In Doug's comments, he asks the rhetorical question "so now the MSH has a
GUI?"
We don't need to tell vendors what to do IMHO. We are only concerned with
what goes on the wire, not how the implementations choose to implement
various features for the user. I second Doug's comment that this note
(which is what it really amounts to, even though it is not identified as 
such) be removed.

<DB>OK, So now if there is an error in the payload it is OK to point to it
and refer to it as if it were an error in the header. 

But what error code would you use?

Now the error codes described in section 8.7.8 only apply to ebXML elements
so they can't be used, and of the ones in section 8.7.9 the only one that
could be used, I think is "unknown" which is not really helpful. If you
really want to remove these lines, then I think we should another error code
called "PayloadError" with an explanation that states "Indicates that the
error is contained within the Payload of the message". Thoughts?/DB>


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

I have no heartburn about adding an id attribute to all top-level
elements so that they can be easily (cross-)referenced. Having the id
element on the Manifest makes it easy to reference from a dsig:Reference
(you can have the URI be an IDREF fro simplicity)

I am not clear as to your point that we don't use id attributes
consistently, unless you mean "we don't provide for an optional 'id'
attribute on significant elements in our schema", in which case I agree.

I'll go with a majority opinion on this. Adding an id attribute is
no big deal unless we go to the extreem that it is required on
all elements for which we provide it, which would make the spec
a little more complicated than it needs to be.

<DB>I also don't have strong views, although I think we should put it on all
top level elements and all repeated element. For example I can see a use
case where an intermediary would sign an additional TraceHeader and want to
sign it separately.</DB>


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

Adding the element is one thing, providing the guidance as to how the
digest value is created is another thing. I would prefer that the security
team provide this input/guidance. 

The problem with including the digest of the received message in the
Signature of the acknowledgment message is that the URI of the Reference
element needs to be resolvable by the validation process of the DSig
implementation. It isn't at all clear to me that this is possible
unless the whole message is included with the acknowledgment as an 
attachment, which I believe we have agreed not to do.

<DB>A very valid point. What I think we need, is a standard way of
referencing any ebXML Message. How about a URN along the lines of:
urn:ebxml.org:MessageId:xxxxxx I think that this could be very useful for
use in signatures.</DB>

I think that this is still related to the issue of the potential
conflict between our spec and the BP spec which also includes
a ReceiptAcknowledgment DTD which provides for the digest value
(as #PCDATA).

<DB>I also agree. But if we think that other standards groups (RosettaNet
for example) might be using TRP, then we should not require them to use BP.
I am therefore thinking that we should include the digest value, but not
specify how it is calculated as Doug suggests.</DB>

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

So, are we then in agreement that the type attribute and the signed
attribute
be removed?

<DB>Yes. And I will include the removal of it when I send in my suggested
changes</DB>

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

Nothing is going to be added to the CPA spec unless you plan on 
confronting Marty with an armed posse of vigilantes;-) I say we remove
this and allow for it to be addressed in XMLP WG and/or whatever comes next
for ebXML TR&P.

<DB>Getting an armed posse from the west coast of the US to the east could
be dificult so I don't think I'll try that. However an earlier email
discussion which involved David Fischer, suggested that whilst the CPAId is
mandatory, the CPA is not. In this case, the MSH Time Accuracy can quite
reasonably stay. </DB>

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

Making TraceHeader required would be a poor alternative IMHO.
It adds no value unless there IS multihop routing and therefore
overcomplicated an implementation without adding any perceived
benefit IMHO.

I would prefer that the From and To be assigned by the MSH based
on some external means. Leave it to the implementation to determine
where to get the logical identifier values if it is an intermediary.
<DB>Chris. I think we are exchanging one type of complexity (requiring that
the TraceHeader be present) by a worse one (leaving it to the implementation
to decide where to send the acknowledgment). </DB>

Of course, This also goes to Doug's repeated, yet unaddressed comments
going back as far as I can recall that SendingURI and ReceivingURI
should in fact be From and To elements, consistent with the From
and To elements of the MessageHeader (e.g. that they are PartyId's
and NOT URL's).
<DB>The purpose of SendingURI and ReceivingURI in the TraceHeader was to
determine the physical route that a message sent. If you replace them by
From and To then you lose this information.</DB>

I have been supportive of Doug's suggestion, yet for some reason it has
never
received the attention that it deserves.

We could solve the issue IMHO by adopting Doug's suggestion that
SendingURI and Receiving URI be replaced with From and To elements
and then this particular issue would be rendered moot (although the
text would still need to be changed accordingly).
<DB>I don't think we will be able to agree this without a lot of discussion
which would be a valuable thing to do and for which there is no time. I
therefore propose that for now we make no changes.</DB>

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

The Timeout parameter was agreed to be removed. It no longer exists
in the CPA nor in the MS specification. I think the language I proposed
is clearer to be honest, but I'm a little biased;-)

<DB>It may have gone from the CPA, but not from the MS/TRP spec (see lines
1398-1401). On your second point, I don't have strong views although
obviously I think mine is better ;)</DB>
> 
> 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
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org