Should we agree more issues on the email list? Was RE: New commen tslist

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

Dick said ...

>>>Perhaps it's time to consider a F2F.<<<

The problem with our F2Fs is that a small quorum of people who are not
representative of everyone on the list can (and do) over-turn parts of the
spec that are based on **consensus** reached earlier on the list. Secondly
new changes and ideas get included without proper discussion with those who
are not at the F2F. This then usually leads to debate and later re-working
and lack of understanding of what's in/out in the spec.

THIS ISN'T THE WAY THE IETF WORKS! In the IETF the F2F meeetings are used to
resolve issues, agreed in advance on the list, that are then finalized. The
email list is the main method of communication. The same goes for the W3C.

It's too late to change anything whilst TRP is operating under the ebXML
approach, but I do suggest we take more care with how we organize ourselves
in whatever is the future home of TRP.

Do other people agree?

Just my opinion ...

Best wishes to everyone.

David

-----Original Message-----
From: Dick Brooks [mailto:dick@8760.com]
Sent: Friday, April 13, 2001 3:24 PM
To: Doug Bunting; david@drummondgroup.com; ebXML Transport (E-mail)
Subject: RE: New comments list


IMO, based on past experiences, we've made the best progress on design
decisions in face-to-face meetings. Perhaps it's time to consider a F2F.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Doug Bunting [mailto:dougb62@yahoo.com]
> Sent: Friday, April 13, 2001 5:06 PM
> To: david@drummondgroup.com; ebXML Transport (E-mail)
> Subject: Re: New comments list
>
>
> List-Unsubscribe:
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
>
> 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?
>
> * 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?
>
> * 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.
>
> * 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?
>
> * 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.
>
> 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.
>
> * 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.
>
> * 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


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org