OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[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