OASIS ebXML Messaging Services TC

[ebxml-msg] Issue#10: 2.1.2 Message Package

  • 1.  [ebxml-msg] Issue#10: 2.1.2 Message Package

    Posted 02-13-2002 15:00
    David's comments in the updated issues list he
    distributed disagreed with the proposed editorial
    change.
    
    My rationale for changing "may" to "can" in this context is
    to remove any possible confusion w/r/t interpretation
    of our intent here. RFC2119 reserves the word MAY for
    reflecting optionality. In the context here, it is not
    expressing optionality but choice or preference.
    
    I will grant that we've used lower case "may" in this
    context, but this will (IMO) lead only to confusion.
    We've been around the block on this issue of RFC2119
    usage a number of times. I think it critical that we
    leave no room for doubt especially as not all readers
    of the specification will have english as their first
    language and may not catch subtleties.
    
    Line 510 currently reads:
    "Implementations MUST support non-multipart messages, which
    may occur when there is no ebXML payload. An ebXML message may
    be sent either as a plain SOAP message or as a [SOAPATTACH]
    multipart message with one body part."
    
    Our intent here is to require that either form be supported
    by a receiving node, but that a sending node MAY choose which
    packaging mechanism to use. What this amounts to is that
    there are really two perspectives at play here, sending
    and receiving ebMS nodes. The sending MSH node actually
    *does* have an OPTION, from an implementation perspective,
    as it can choose to package the message either way, where as
    the receiving MSH MUST be prepared to process either form.
    
    I would actually suggest that this issue be addressed
    not solely by changing the "may" to a "can" by by being
    explicit as to what we mean here. I would therefore
    propose that we replace the paragraph at line 510 in
    David's draft with the following text:
    
    An ebMS MSH implementation MAY package a message containing
    no application payload, as in the case of an Acknowledgment
    message carrying no application payload, either as a
    multipart/related message as described in [SOAPATTACH] containing a 
    single body part, or as described in [SOAP] using the text/xml
    MIME content-type. An ebMS MSH implementation MUST be capable of 
    processing received messages that arrive in either form.
    
    Cheers,
    
    Chris