[Fwd: Re: Sender sub-elements optional or required]

[Colleen Evans <cevans@sonicsoftware.com>]

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