Connected again: Here's the rest of my comments on 0.21d

ebxml-transport message

Deep breath, here we go with the rest of my comments (including DTD and schema recommendations):
Sections 7.9.1, 7.9.2.1 and 7.9.2.2, lines 615-617 and 633-638:
These values (PartyId, TPAId and ConversationId) appear to be strings meaningful in a particular context. Without the optional context attribute, they must take the form of a uriReference. When a context attribute is provided, they may take any value valid in that context (whether or not that's a valid uriReference). Add words describing these identifiers as strings. Add words describing the semantics of the context attribute (just improve the wording for lines 615-617).

Section 7.9.3.3, lines 669-671:
Error messages may be sent in response to Normal messages in which no MessageId could be found. There is an earlier message, but its MessageId is unknown. This case should be described in this paragraph. An additional sentence such as "For Error messages, the RefToMessageId reference is mandatory and its value MUST be the MessageId of the message in error (as defined in section 7.13.1) unless that MessageId cannot be determined." Hopefully, we're not trying to support Error messages containing errors found in multiple original (Normal) messages.

Section 7.10, lines 713-715:
SenderURI, ReceiverURI and ErrorURI are not defined. Are they identifiers or service locations? From later discussion in this document, it appears that ErrorURI is a service location at which error responses may be received. The other two aren't discussed much. However, I'd recommend they be defined similarly to the PartyId elements in the Header (ie. the parties participating in the current leg of the journey). That requires adding a context attribute to SenderURI and ReceiverURI and (potentially) renaming the elements. Alternatively, SenderURI and ReceiverURI may somehow identify the service location used in this particular leg (this is probably redundant information for ReceiverURI with the transport destination and SenderURI may not exist -- not all senders are reachable in return).

Section 7.10, lines 719-730:
SequenceNumber as defined adds little or no value over the MessageID element required in MessageData. Recommend removing this section and the corresponding references to SequenceNumber in later examples, the DTD and the schema.

Section 7.10, line 727:
If this section remains, must define the exact content of the SequenceNumber element when the numeric value is greater than 999. Is the next value "1000" or "1,000"? Is the text for the maximum value "999999999" or "999,999,999" or are both allowed (and equivalent)? Side note: Numeric formats vary by locale and a comma is not always the thousands separator. Further, "Punctuation as in US English." (to quote the "Specific Datatypes" section of the http://www.w3.org/TR/1998/NOTE-XML-data-0105/ document) doesn't answer my questions above.

Section 7.10, line 730:
If this section remains, "long time" should be defined. At least, refer to a TPA which makes this concrete for a specific trading relationship or mention later text on this subject (if any).

Section 7.11, lines 754 and 771 (at least):
"Persistent storage" actually lasts how long? Is the original message deleted by the Messaging Service immediately after receiving an acknowledgement? In the case of an error which is reported to the sending application (party), does that report also result in deletion of the original message from the persistent storage?

Section 7.11, lines 784-787:
What information does the Receiver store persistently in this step? Recommend storing the MessageID of the original message and the entire response document. To check for "exactly the same as the original message" as described on line 828, may be necessary to store entire original message or its checksum as well.

Section 7.12, line 817:
The Timeout and RetryInterval parameters have different semantics as described later in this document. However, that difference is not made clear in this table. Recommend RetryInterval definition be changed to "Wait time between receiving notification of a transport error and sending a retry.
* Integer value specifying number of seconds.
* After any error response is received, the Sender SHALL wait for the specified time before sending a retry document." If the intended semantics of RetryInterval require that documents not be send more often than the specified interval (requiring the Sender to wait for a timeout, declaring that status and then beginning a wait for RetryInterval), that could be described by changing my words above to include a bullet such as "* Notification of a transport error includes detecting an expired timeout while awaiting a response."

Section 7.13.4, lines 892-907:
The wording of this section explicitly prevents leaving out the ErrorURI and relying on the immediate response available in some transports. For example, sending a message via HTTP may not require the ErrorURI because the receiver always completes MS handling in "real time" and returns an Error document (if necessary) in the immediate HTTP response. Recommend this case be supported by including words to this effect rather than leaving it "outside the scope of this document".

Section 7.13.5.3.4, lines 948-951:
Either the Description element should be allowed to repeat (providing multiple descriptions of the error in various locales) or a Normal message should specify the preferred locale for Error messages. Without this, the Description content is not going to be useful with multiple, interoperating systems.

Section 7.13.5.5.2, lines 1004-1006:
How does this RefToMessageId relate to the one in MessageData? Since we aren't attempting to handle an Error response covering multiple messages in error (right?), change the last sentence to be "This must be present [and have the same value as the RefToMessageId in the MessageData element of the Header] if a MessageId can be identified in the message in error."

Section 7.13.5.7, lines 1024-1043:
Either the DTDs and schemas are normative or not. It doesn't make sense to handle the DTD for ebXMLError differently from the DTD and schema for ebXMLHeader. Move this section to a (new) appendix A.3. By the way, appendix A should be normative though it isn't necessary for it to interrupt the regular flow of the text.

Section 7.13.5.7, line 1027:
This is likely a duplicate. Just wanted to make sure we noted that "<schema ...>" either shouldn't appear in the DTD or must be a processing instruction ("<?schema ...?>").

Section 7.13.5.7, line 1028:
According to the text of section 7.13.5.5, we've got a meaning for a minimum of one ErrorLocation element. Either change "ErrorLocation*" to "ErrorLocation+" (requiring one or more such element) or define the meaning of zero ErrorLocation elements in section 7.13.5.5. For the second resolution, add "If no ErrorLocation element is provided, no information about the specific location of the error is available. When a MessageId can be determined from the message in error, the ebXMLError must contain one or more ErrorLocation elements." to the end of section 7.13.5.5.

Section 7.13.5.8, lines 1049-1052:
Are the two "narrative" types of information contained in the Description element or the ErrorCode? Replace "that immediately follows the error code" with "beginning the Description element" on line 1049. And, replace "that follow the narrative" with "that follow the narrative (completing the Description)" on line 1051.

Section 8.1, lines 1118-1120:
The Internet Draft on XML Media Types is now an RFC. RFC 2376 (XML Media Types) has been available since July 1998. That document must be normative for this specification. Update the reference in these lines.

Section A.1, lines 1238-1287:
The DTD uses Extensibility mechanisms for including datatype information. Either here or in section 8.2, add a non-normative reference to some description of these mechanisms.

Section A.1, line 1239:
This is likely a duplicate. Just wanted to make sure we noted that "<schema ...>" either shouldn't appear in the DTD or must be a processing instruction ("<?schema ...?>").

Section A.1, lines 1242-1243:
To validate any of the given examples, need definition of the xmlns pseudo-attribute (it's an attribute as far as a parser with no knowledge of namespaces is concerned). Add 'xmlns CDATA #FIXED "http://www.ebxml.org/namespaces/messageHeader"' to the ATTLIST. Note: There's no way to require an attribute with this value in every instance document in a DTD. A #FIXED attribute is (unfortunately) optional in a particular document.

Section A.1, line 1243:
This definition of the MessageType attribute prevents any values except "Normal" and makes it optional in a document. In addition, the text of section 7.7.1.3 says this attribute is an enumeration. Change this line to read "MessageType (Normal | Acknowledgment | Error) #REQUIRED".

Section A.1, line 1244:
Requiring one or more DocumentReference elements in a Manifest disallows a message of type "Acknowledgment". We need to support an empty Manifest. In addition, the DTD and schema disagree on this point (the schema appears to be correct). Change the "+" at the end of this line in the DTD to "*".

Section A.1, lines 1251, 1260, 1263, 1273, 1279, 1281 and 1283:
Depending upon the resolution of my previous comments on the PartyId, TPAId, ConversationId, SenderURI and ReceiverId, their datatypes should change to 'string' and a few might be renamed and / or they could gain a context attribute. Regardless of those changes, the "uri" datatype doesn't exist in the W3C Schema proposal. The closest type is "uriReference" and we should either use W3C Schema datatypes consistently or describe their equivalents in the DTD (for the elements which continue to have this type, which might be only DocumentId, PartyId and Href).

Section A.1, lines 1259, 1262 and 1272:
The context attribute has no defined default value according to the text of the one element (PartyId) which mentions it. Use of a default such as "Undefined" for the TPAId, ConversationId and PartyId element's context attribute adds no value over leaving the attribute out completely. It also changes the "experience" of a receiving application depending upon the configuration of the underlying XML parser. Change 'Undefined' to #IMPLIED on each of these lines.

Section A.1, line 1264:
The RefToMessageId element is optional in this context (as it is in ErrorLocation) according to the text of section 7.9.3.3. Add a "?" after this element in the MessageData element.

Section A.1, lines 1264 and 1268:
The "uuid" datatype doesn't exist in the W3C Schema proposal. Further, this datatype in the XML Data proposal (which Extensibility referenced as normative) requires a particular format for the unique identifier (128 bits expressed in hexadecimal format). As long as these values are globally unique, we should not restrict implementations that much. For example, a value created according to the rules for a MIME content identifier would be fine. Change the datatype of these values to be "string".

Section A.1, line 1275:
This definition of the DeliverySemantics attribute in ReliableMessagingInfo prevents any values except "BestEffort" and makes it optional in a document. Change this line to read "... #REQUIRED" instead of '... #FIXED "BestEffort"'.

Section A.2, lines 1294-1295:
The RoutingHeader element should be optionally allowed in the ebXMLHeader element. Add '<element ref="RoutingHeader">' after the Header line in this sequence. Also, define the content of that element (to match the definition in the DTD) later in the schema.

Section A.2, line 1298:
This definition of the MessageType attribute prevents any values except "Normal" and makes it optional in a document. In addition, the text of section 7.7.1.3 says this attribute is an enumeration. Change this line to read
    <attribute name="MessageType" use="required">
        <simpleType base="ENUMERATION">
            <enumeration value="Normal">
            <enumeration value="Acknowledgment">
            <enumeration value="Error">
       </simpleType>
    </attribute>

Section A.2, line 1310:
This sequence should not have minOccurs or maxOccurs constraints since it is a simple sequence of the contained elements. The element containing DocumentReference (Manifest) already allows it to repeat as described in the text. Remove these constraints.

Section A.2, line 1311:
In addition to the above point, the DocumentDescription element is not defined in the schema. After line 1316, add
    <element name="DocumentDescription">
        <complexType>
            <simpleContent>
                <extension base="string">
                    <attribute name="xml:lang" type="language" />
                </extension
            </simpleContent>
        </complexType>
    </element>
This might not be correct in the W3C schema language: It's my best guess.

Section A.2, lines 1336, 1341 and 1375:
base is not a valid attribute for the complexType element and textOnly is not a valid value for the content attribute. This probably requires something similar to the previous suggestion.

Section A.2, lines 1336, 1341 and 1375:
Depending upon the resolution of my previous comments on the PartyId, TPAId, ConversationId, SenderURI and ReceiverId, their datatypes should change to 'string' and a few might be renamed and / or they could gain a context attribute. Regardless of those changes, the "uri" datatype doesn't exist in the W3C Schema proposal. The closest type is "uriReference" (for the elements which continue to have this type, which might be only DocumentId, PartyId and Href).

Section A.2, lines 1337, 1342 and 1376:
The context attribute has no defined default value according to the text of the one element PartyId which mentions it. Use of a default such as "Undefined" for the TPAId, ConversationId and PartyId element's context attribute adds no value over leaving the attribute out completely. It also changes the "experience" of a receiving application depending upon the configuration of the underlying XML parser. Remove 'use="default" value="Undefined"' on each of these lines.

Section A.2, line 1354:
The RefToMessageId element is optional in this context (as it is in ErrorLocation) according to the text of section 7.9.3.3. Add 'minOccurs="0"' to this element in the MessageData's content.

Section A.2, lines 1354 and 1358:
The "uuid" datatype doesn't exist in the W3C Schema proposal. Further, this datatype in the XML Data proposal (which Extensibility referenced as normative) requires a particular format for the unique identifier (128 bits expressed in hexadecimal format). As long as these values are globally unique, we should not restrict implementations that much. For example, a value created according to the rules for a MIME content identifier would be fine. Change the datatype of these values to be "string".

Section A.2, lines 1381:
This definition of the DeliverySemantics attribute in ReliableMessagingInfo prevents any values except "Unspecified" (which isn't valid in according to the enumeration) and makes it optional in a document. Change line to read 'use="required"' instead of 'use="fixed" value="Unspecified"'.

Section B.1, line 1417:
The text of this specification does not make it clear how the DTD should be referenced in an instance document. A relative URI implies that all parties have already cached the DTD. Recommend a fully qualified location on the Internet (using the http scheme) for these files.

Section B.1, line 1445:
The RefToMessageId element should be optional. Leave it out of the example rather than using an undefined "placeholder" value such as 'Not Applicable'.

Section B.2, line 1565:
The RefToMessageId element should be optional. Leave it out of the example rather than using an undefined "placeholder" value such as 'Not Applicable'.

Section D, lines 1664-1667:
Why would browser vendors directly implement any semantics defined by multipart/related (even) or ebXML? The application-level requirements of ebXML don't lend themselves to a display interface. Business code downloaded to operate in the context in a browser (Active X or Java, whatever) may implement all of ebXML without additional work done by the browser itself. Remove this paragraph.

Section E.1, lines 1672-1680:
This binding to HTTP explicitly prevents optimizations using the immediate HTTP responds to carry an acknowledgement, error or business response. It also prevents ebXML implementation using an HTTP client without an associated HTTP server available directly from the Internet (not hidden behind a firewall). Delete this section and revisit all of the contained materials while implementing later phases of this project.