[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [Fwd: Re: Sender sub-elements optional or required]
Colleen, As discussed on today's call, here's the email in which I provide the corrected Signature example fragment. As stated in the email, the example is incorrect, the normative text is correct. http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00289.html This should close (fixed) issue #75 raised by DavidF. Cheers, Chris Colleen Evans wrote: > > This is the first of 3 emails I'm posting to the list > documenting editorial > changes made to V1.1. These changes were not included in > the issues log that David Burdett distributed on Sept 5. > > Colleen > > -------- Original Message -------- > Subject: Re: Sender sub-elements optional or required > Date: Wed, 15 Aug 2001 00:36:05 -0400 (EDT) > From: Dan Weinreb <dlw@exceloncorp.com> > Reply-To: "Dan Weinreb" <dlw@exceloncorp.com> > To: cevans@sonicsoftware.com,david.burdett@commerceone.com > > Date: Tue, 14 Aug 2001 09:35:15 -0600 > From: Colleen Evans <cevans@sonicsoftware.com> > > If you don't want to send your editorial level > suggestions to the entire > list, please send them to David Burdett and me. > > OK, here goes. > > Lines 625 - 633: It would be nice to have these in the same > order as the > subsections of the spec that describe them. > > Line 864: Can you really specify it in the MessageHeader? I > didn't > see a way to do that. > > Line 895: The mention of "storage required" seems somewhat > out of > place since the whole concept of "storage" has never been > discussed > and doesn't seem to be part of the overall model of the > protocol, > IMO. > > Lines 992, 993, 1010, 1011, 985 - 998 should say whether > these things > are required or optional, in order to be useful and to be > consistent > with the rest of the descriptions in the spec. > > Line 1003: I don't understand about "another URL"; under > what circumstance > would there be another URL? > > Line 1004: "when required that" is not grammatical. I think > a word is > missing. > > Line 1220 and all of section 8.7.4: It says what the two > values are, > but it ought to try to explain what they *mean*! > > Line 1256: "ydda" should be "yadda". Hey, these things > matter... > > Line 1187: Should say whether Via is optional or required. > > Line 1367: Say whether Manifest is required or optional. > The answer > is at line 1527... > > Line 1405 (section 8.11.3.1): Why would you ever have more > than one schema? > This should be explained. > > Line 1429: "the payload container of the message" isn't > right; a message > can have many payload containers. Maybe "the corresponding > payload > container of the message"? > > Lines 1545-1546 seem to contradict line 1538. > > Line 1553: If DeliveryReceipt can be combined with other > things then > it really needs its very own RefToMessageId rather than > trying to use > the one that's already there, which is being used by other > elements. > > Line 1558: Why say "One-and-only-one" instead of just > "required" > as elsewhere, or "a/an" as in lines 1552 & 1554? > > Line 1580: Talks about "no ebXML Payload", but the term > "ebXML > Payload" has never been used! It would be better to say > that there > are no ebXML Payload Containers, or else the term "ebXML > Payload" > should be defined. I realize I'm nit-picking here; nobody > will have > any trouble understanding this but I think it looks sloppy > because I'm > just picky about reference documentation... > > Line 1686: Should "8.15.8" really be "8.9"? > > Line 1692: Ah, the explanation of what the "transport" value > means up > at line 1220, but this section doesn't mention the names of > the two > values... > > Line 1708: "semantic" => "semantics" > > Line 1778: I think this needs to say to wait for the > particular Ack message > that acks what I sent, not just wait for any old Ack > message. > > Line 1788, actually all of section 10.3.2: does this apply > to ErrorList, StatusRequest, DeliveryReceipt messages? > > Line 1794 seems to be assuming that if there is a > RefToMessageId, > then there must be an Acknowledgement; but RefToMessageId > can be > there for many other reasons... > > Line 1817: Are you saying that an "acknowledgement message" > might not have > an Acknolwdgement element?? > > Line 2012: [XMLC14N] ought to be in chap 13. Actually > someone should > make a pass over the whole spec looking for references to > documents > and making sure those references are actually in chap 13; I > think > there are others like this. See line 2847's [ESMTP]. > > Line 2816: It is not clear what "the response message" means > here; > that term hasn't been used previously, I think. > > Line 2845: What's this about peer-to-peer trust models? > SSL3 is based > on PKIX and X.509, and they don't use peer-to-peer trust > models. > > Line 354: We use the term "communication protocol", but the > CPP/A > document uses the term "transport protocol". > > -- Dan > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
begin:vcard n:Ferris;Christopher tel;cell:508-667-0402 tel;work:781-442-3063 x-mozilla-html:FALSE org:Sun Microsystems, Inc;XTC Advanced Development adr:;;;;;; version:2.1 email;internet:chris.ferris@east.sun.com title:Sr. Staff Engineer fn:Christopher Ferris end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC