Re: Comments on message header spec., v.0-63, 7/27/00

[mwsachs@us.ibm.com]

Chris,

The earlier discussion was from me on the TRP list  couple of months ago.
That time, I was looking for advice on how to handle the "optional" problem
in tpaML.  Someone blew the train of thought by responding with a post
about the difficulties of conformance and no one ever responded to my
question.

"Not required" would have the same RFC2119 difficulties as "optional" since
"required" is an RFC2119 word.  Explicitly mentioning cardinality is the
safest apporach although it can result in some pretty ugly sentence
constructions.

Regards,
Marty

*************************************************************************************

IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Chris Ferris - Sun East Coast IR Development
<chris.ferris@sun.com>@xroads.East.Sun.COM on 08/09/2000 05:29:53 PM

Sent by:  cferris@xroads.East.Sun.COM


To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   ebxml-transport@lists.ebxml.org
Subject:  Re: Comments on message header spec., v.0-63, 7/27/00



Marty,

Some comments below. Thanks for the great feedback!

Chris
mwsachs@us.ibm.com wrote:
>
> COMMENTS ON MESSAGE HEADER SPEC, 07/27/2000
>
> 2.1  PRINCIPAL HEADER ELEMENTS
>
> Line 163:  This states "any additional header elements are optional".
This
> use
> of "optional" probably does not conform to RFC2119 since I assume that
> "optional"
> here means that the DTD specifies either "0 or 1" or "0 more more".  In
> RFC2119,
> "optional" means that an implementation may or may not support the
feature.

Yes, I've seen this same discussion elsewhere regarding use
of 'optional'. Can't recall whether it was transport or
architecture team which brought it up.

>
> In general, the term "optional" is problematical in XML with regard to
> RFC2119
> conformance because I find it very hard to write text about "0 or 1" or
> "0 or more" without using the word "optional". I went so far as to
consult
> Roget's Thesaurus and could not find an acceptable synonym.  With regard
to
> "0 or 1" and "0 or more", an implementer should generally be required to
> support the tag.  I suggest modifying the RFC2119 conformance statement
to
> say
> "except for the word 'optional'" and to further state that when
"optional"
> refers
> to a tag which may appear 0 or 1, or 0 or more, times, all implementers
> shall
> support this tag.  See tpaML draft ver. 1.0.6 for an example of such
text.

Another approach we might consider is use of the phrase
'not required' to represent 0 or 1. Another approach might
be to explicitly call out the cardinality in the description.

e.g.
element        cardinality
foo       0 or 1
bar       0 or more
baf       1 or more

Just a thought.

>
> Please scrub the spec for any other uses of "optional".
>
> Since there are currently no such optional header elements, as far as I
can
> tell
> from the DTD, an immediate solution is to delete the sentence containing
> this
> word at line 163.  However I recommend modifying the RFC2119 statement as
> above
> in order to be ready for the introduction of such optional elements.

Agreed. We'll have to see what the merged and revised revised
specification looks like to make any of these changes.

>
> 4.  MESSAGE TYPES
>
> Line 318:  What is "transport specific message"?  To me, a transport
> specific
> message is an acknowledgment or error message generated by the transport
> protocol and having no content to be processed by the application.  Such
a
> message won't have an ebXML header or envelope and will be sent on the
> connection created to send the message to which the ACK or error message
is
> responding.

Well, in part, this is correct. We should be more specific
and indicate that it is an ebXML Message Service specific message
as distinct from a transport specific message which as you rightly
point out is an ack or error reported via the connection
on which the message is sent.

An ebXML Message Service specific message is intended to
be asynchronous. It takes the form of an ebXML Message
(MIME multipart/related package with an ebXMLHeader body
part and an optional (0 or more) payload. The Acknowledgement
has no payload, whereas an error would have a payload,
yet to be specified, which contains the error information
(code, description or error text, context, etc.)

>
> 4.1 WHAT IS A MESSAGE TYPE
>
> Line 324:  What is "ebxml aware transport"?  This must refer to the
message
> system.

agreed.

> To avoid confusion, I suggest that the word "transport" be used only
> to refer to transport-protocol functions (e.g. HTTP, SMTP) including the
> communication protocol and associated security functions at this level
> (e.g.
> SSL).

agreed.

>
> Regards,
> Marty

--
                               Christopher Ferris
    _/_/_/_/ _/    _/ _/    _/ Enterprise Architect - EMA
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903