RE: [ebxml-msg] issues list

[David Fischer <david@drummondgroup.com>]

Title:

Thanks Chris,

I'm sorry, I have not responded to these comments because they were submitted after the deadline.

If you feel that some of these comments were submitted prior to the deadline or that some of my responses to previous comments were incorrect, then please bring those to the attention of the group and we can vote on them.  My responses are only the opinion of the editor and do not constitute a decision by the group.  In many cases, I have tried to resolve conflicting requests from numerous parties.  If you feel the resolution was not correct, then please bring it up.

One such case, which I see from your comments, is whether to have Acks on Errors or Errors on Acks (but not both).  Originally, the decision was Errors on Acks, then you made your opinion known that you preferred Acks on Errors (reliably sent Errors).  As soon as I changed the spec to reflect your opinion, several other members spoke out against the change and put forward a substantial case for our original decision -- Errors on Acks.  Since you (nor Doug) responded, I changed back to the original decision.  I was originally neutral on this issue, but I think I have become convinced from the discussion on the list that Errors on Acks is correct.  At this point, it effectively takes a 2/3 vote to change anything, but since this issue was definitely open prior to the deadline, perhaps we should take it up yet again.  Please read the attached message.

Regards,

David Fischer
Drummond Group
ebXML-MS Editor.

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Wednesday, January 30, 2002 2:36 PM
To: ebXML Msg
Subject: [ebxml-msg] issues list


All,

As mentioned on the call, I have tweaked the W3C XML Protocol WG
issues list for our needs, and have established as a baseline the
issues I raised with my vote on 2.0.

Attached are the XML, XSLT, DTD and HTML, all of which should be
posted to our website. We need to be sure that the DTD retains the
W3C IP disclaimer.

Comments welcomed. I'll gladly make any necessary changes
to the schema or styling.

Cheers,

Chris

---

• From: "Cliff Collins" <collinsc@sybase.com>
• To: "David Fischer" <david@drummondgroup.com>
• Date: Wed, 23 Jan 2002 13:30:22 -0600

Below is the last message I sent on this issue. Others did a
+1 but Chris
never replied since he was on vacation.

Cliff

PS. one things I forgot to note in response to Chris'
message was that:

Some message will request acks(receipts) that will be used
in situations
that are not "once and only once" so there would be no
retry. Instead, this
would result in no error reported to the sender.

-----Original Message-----
From: Cliff Collins [mailto:collinsc@sybase.com]
Sent: Monday, December 10, 2001 2:19 PM
To: Christopher Ferris
Cc: ebXML Msg
Subject: RE: [ebxml-msg] Ack on Error, or Error on Ack


>
>
> I don't get error on ack at all. If I receive an
> acknowledgment message, and for whatever reason cannot
> process it (let's say it was mangled in transit)
> then I'll simply resend the original message
> until I get an ack, or until either the message's TTL
> expires or the retries have been exhausted at which
> time I'll notify the application that I have not
> received an acknowledgment confirming the message's
> receipt by the intended recipient.

Acks can now also be used for Non-repudiation of receipt.
This means that if
the ds:References are not included or it is not signed and
the CPA says it
was suppose to be than this is an ERROR of inconsistent.
Waiting for the
retry doesn't solve the error.


>
> As for ack on error, why on earth cannot an error
> be treated with all of the same QoS as a normal
> message?!?!? What if the recipient wants to be sure that
> the original sender is notified that there has been
> a problem in processing the message? Seems perfectly
> reasonable to me to allow this.

I look at this another way, since errors (in general) are
generated by the
MSH in response to a message they are not a reliably sent
message any more
than we would make "acks" be resent automatically. The error
is in response
to a message. If the sending MSH sends the message again, we
would error
again, not the other way. This is in contrast to continually
sending an
error for a message we received that was in error.

>
> The circularity comes only (IMO) when you error on
> an acknowledgment because this would require that
> the sender of the acknowledgment provide for the
> ability to process the error (as well as for specification
> as to what processing is required which is currently
> not addressed in the specification).
>
> IMO, the only thing that the spec should say is that
> an ack cannot be requested for an acknowledgment message.
>
> Cheers,
>
> Chris
>
>
> Cliff Collins wrote:
>
> > I like Error on Ack (like the 1.0 model) the best.
> >
> > If we allow Ack on Error then it becomes really messy
when there is a
> > failure on the Ack message. And when the retries are
reached on
> sending an
> > "error" over RM does this generate another error of
delivery
> failure? Messy
> > :-)
> >
> >
> >>-----Original Message-----
> >>From: David Fischer [mailto:david@drummondgroup.com]
> >>Sent: Monday, December 10, 2001 12:30 PM
> >>To: ebXML Msg
> >>Subject: [ebxml-msg] Ack on Error, or Error on Ack
> >>
> >>
> >>I did not get to bring this up today so I will try
eMail.
> >>
> >>If we allow both Ack on Error and Error on Ack, we have
the
> >>potential for an
> >>infinite loop.  Either is fine but not both.
> >>
> >>First we chose to allow Error on Ack but not Ack on
Error (no
> >>Error messages
> >>sent reliably).
> >>
> >>There was some dissention, so we changed to allowing Ack
on Error
> >>but not Error
> >>on Ack (Error message can be sent reliably but if there
is
> >>something wrong with
> >>an Ack there is no notification).  Now there is
dissension the opposite
> >>direction  ;-(
> >>
> >>I prefer Error on Ack since it seems redundant to send
an Error
> >>reliably and I
> >>would like to know if there is a problem on my Ack.  I
will be
> >>happy either way
> >>but we need to decide (and quit sending me complaints).
> >>
> >>Which way?
> >>
> >>Regards,
> >>
> >>David Fischer
> >>Drummond Group.
> >>ebXML-MS Editor.
> >>
> >>
> >>
>
>>----------------------------------------------------------
------
> >>To subscribe or unsubscribe from this elist use the
subscription
> >>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
> >
> >
>
> ----------------------------------------------------------
------
> > To subscribe or unsubscribe from this elist use the
subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
>
>
>
> ----------------------------------------------------------
------
> To subscribe or unsubscribe from this elist use the
subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>

---