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