Comments on ebXML TRP v0.1 of the Messaging Service Specific atio n

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

Comments on ebXML Transport, Routing & Packaging Messaging Service
Specifications (August 10 draft)

1.	"attributes " and "parameters"

line 143: The MIME and HTTP/SMTP conventions always assume
that the header field-name is case-insensitive for matching operations.
Values in a field-body (the stuff after the colon) can be case-sensitive
(see RFC 822, 3.4.7) . Mime content-type values are case-insensitive;
(RFC 2045, section 5.1) and parameter names are case insensitive (ibid).
The term "attribute" is really more an XML term than a MIME term 
for a syntactical unit. The way the language reads now it suggests 
that any value in the header is to be matched in a case-insensitive 
way. Is that what is wanted? I don't think so, especially for 
Message-ID and Content-Id values, for example. 

Also if the parts of the header of the form "parameter=value
*(;parameter=value)"  
are going to be called "attributes," a terminological warning should be
given 
so that people burdened with IETF terminology don't get confused ;-)

2.	TPAInfo optional if the message is for setup/discovery (bootstrap
issues)

If the discovery  service messages are to conform to 
the XML standard, then because these messages may occur 
without a TPA id being in place or known, the TPAInfo element 
may need to be optional in the ebXML header. An alternative 
might be to make the entire header optional for the discovery ebXML message.
I think this special case needs clarification. 

3.	MIME, XML, Crypto parsing error messages.

Within RosettaNet, it has been learned that three serious 
error categories (above transport level errors such as " 404 File 
not found" but below ebXML business level errors) are difficult 
to report on while using XML payloads. These are: MIME parse errors, 
XML parse errors, and Security errors (preventing, for 
example, decryption). While these errors tend to occur 
around new version releases, when enough vendors and home-grown
implementations get involved, 
they will probably be a common pitfall and 
obstacle to transparent interoperability. I don't see the 
treatment in this draft (or reference to another to-be-written 
spec) on how these error reporting situations are treated. 
The usual problem here is that when error conditions of these 
types arise, the other end can't get far enough along in 
its parse to fill out the XML based header on the return message.
RosettaNet has a proposed provisional way to deal with these
error categories in v2.0 of its RNIF.


4.	<pedestrianSyntacticalQuibble> 
line 203. A Content Id value is to have the same syntax as 
a Message Id (RFC 2045,section 7) , so in the example, 
the string should begin with '<' and end with '>'. 
(The BNF++ is " msg-id =  "<" addr-spec ">") The 
explanation of the cid: URI  presumes that the content-id 
has this syntax, because it strips off the "<" and ">" to 
avoid conflicts with XML lexical rules. In practice, I 
think you will almost certainly find people ignoring 
this syntax, and the part about having an "addr-spec" 
inside the brackets-good luck-universally ignored except 
by mailers. Nevertheless, since this is a specification 
it should not conflict with other specifications and so 
throughout all the example PDUs, the values should look 
like legal Content-Ids.. I think that since people tend 
to copy examples when implementing-and ignore the 
verbiage-it would be a good idea to have Content-ids 
like "afds78904321quafouipq@ebxmlhost.realm" 
</ pedestrianSyntacticalQuibble>