Re: New comments list

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

Doug,

Some thoughts below.

Cheers,

Chris

Doug Bunting wrote:
> 
> A few clarifications and questions on my comments and those others have
> submitted:
> * What does the status "defer" mean at this stage in the game?

Defer until at least Vienna and more likely to what ever comes next.

> 
> * In general, it seems the Editorial team has accepted technical
> changes that resulted in disagreement on the list.  For example, Chris
> and I agreed that Shimamura-san's comment 192 should not be accepted as
> is.  Yet it was.  What is going on?

Actually, what was accepted was the fact that the URI was a typo
(looks like a global change was applied changing 'disg' to 'ds' which
resulted in the correct identifying URI for XMLSignature being
mangled). Same holds true for the date, which should be 2000/09
and not 2000/02.

The comment regarding use of a namespace prefix (as you and I both
pointed out) is in fact inaccurate and will not be incorporated.

> 
> * Similarly, the editorial team decided to accept change 106 by putting
> quotes around the required "ebXML" value for the SOAP action header.
> The alternative of removing this value entirely (using the "null"
> option) has not been discussed to reach concensus.

Here I agree. I have consistently held that we should not be
establishing an ebXML specific SOAPAction but leave it to 
implementations/deployments to choose as they see fit.

> 
> * A number of my comments revolve around proposals I'd made that were
> accepted but never properly applied to the document.  For example, my
> timeout proposal (removing this useless thing) still hasn't been
> applied.  Again, what is going on?

Indeed. A quick review finds that the Timeout "parameter" is still
listed even though it was agreed that it be removed. I certainly
has been removed from the CPA specification. I had suggested replacement
text for 1507-1516 which removes the notion of a timeout parameter.
That would also require that the section starting at line# 1398 also be
removed. I certainly concur that having timeout and retryInterval
is confusing at best. Let's go with what we agreed to do a while
back and remove it. I can resurrect the agreement if need be.

> 
> * My comment number 144 (on line 392 or so) comes back to my original
> proposal to resolve the identification / location mismatch in the
> current specification.  We can't define SenderURI as a location and
> expect it to be useful as a From value (an identifier).  Without my
> PartyId proposal, these things simply don't tie together.

I certainly concur with this observation. I would much prefer that
instead of SenderURI that To|From/PartyId be used in the TraceHeader
with the same semantic meaning. Let the implementation figure out
what the URL is for the appropriate transport as it sees fit.

> 
> This particular comment about the words "physical location" go to one
> side of the problem: A physical location doesn't provide enough
> information to identify the controlling party.  (How would I know that
> identifies a service controled by Ariba?)  And, an email address isn't
> really "physical" in any sense.  The other side of the problem is
> requiring a single identifier for each party.  Even EDI doesn't have
> that restriction.
> 
> * We previously had a reasonable way to express the semantics of the
> RefToMessageId attribute in the MessageData element.  With the Message
> Status service in its current form, this is getting very confused.  I'd
> suggest we follow the various comments that amount to putting a new
> RefToMessageId element in the body of the Message Status Request and
> Message Status Response documents.  It doesn't matter that much whether
> they're within the SOAP Body directly or under the StatusData element
> (for the response).  Both are necessary.

I have made similar comments on David's proposal.

> 
> * Reliable Messaging remains confused by additional "requirements" that
> were never on our list.  For example, we've convinced ourselves we
> don't know what a signed Delivery Receipt means but still have it
> somewhat supported.  I'd vote for almost any simplification of the
> parameter list and description in chapter 10.  "Tiny" confusions such
> as not requiring a receiver to deliver anything to the application
> (section 10.3.1.2) would become more obvious.  And, maybe they'd get
> fixed rather than covered by the confusion.

What DeliveryReceipt, signed or otherwise has to do with RM is beyond me;-)
In addition, because technically, a DeliveryReceipt is a business-level
message, I have consistently been reluctant to include it in our spec.
I recognise the sentiment that we want to keep our specification
separate from the others in terms of interdependency, but in all 
honesty we shouldn't be specifying redundant yet different solutions.
IMHO, DeliveryReceipt is either defined in the BP spec or ours, but
not both. 

I reiterate my original question as regards to DeliveryReceipt in the
context of the MSH... "What on earth is the MSH going to do with it?"
Only the application really cares if the message was ultimately delivered
to the receiving party, and as I believe Dick has pointed out, it is receipt
by the receiving application that matters in this case, not the MSH.

I for one would be happy if we removed DeliveryReceipt altogether
from our spec.

> 
> * Similarly, we should resolved such open issues as who Error messages
> are addressed to (who is the To party) and not just where they get
> sent.  Going further, are intermediate parties required to forward
> errors?
> 
> thanx,
>     doug
> 
> --- David Fischer <david@drummondgroup.com> wrote:
> >
> >
> > -----Original Message-----
> > From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com]
> > Sent: Friday, April 13, 2001 5:18 AM
> > To: david@drummondgroup.com
> > Cc: ian.c.jones@talk21.com
> > Subject: New comments list
> >
> <SNIP />
> 
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org