OASIS ebXML Messaging Services TC

  • 1.  Addressing comments from Martin C. : proposals

    Posted 10-13-2010 19:55
    
    
    
    
    
    
    
    
    
    
    

    Addressing comments from Martin Chapman (identified M1 – M5):

    -----------------------

    M1- Line 394: editorial - please spell out the acronym MSH (I think this is its first use in the doc).

    Proposal: add “MSH” entry in Terminology 2.2 (MSH is only casually defined in Core V3, but deserves a better definition status…)

    “MSH: Message Service Handler assumed here to be conforming to ebMS V3 Core specification as well as to features described in this specification (Part 2).”

    -----------------------

    M2- Line 408 and 490: talks about not modifying the SOAP message, I assume you mean soap headers and soap bodies - if so it might be worth saying this explicitly.

    Proposal: Clarify “without modifying the SOAP message or any attached payload à without modifying the SOAP message (SOAP envelope and its content) or any attached payload

    -----------------------

    M3- Line 3093: "as these four feature sets are largely independent and composable in various ways."  This sentence doesn't parse - remove "as"?

    Proposal:

    Extend: This conformance clause is defining four conformance profiles:

    as

    This conformance section is defining four conformance profiles (or clauses) that address the four major feature sets specified here (multihop routing, message bundling, advanced interaction patterns, and message splitting). Indeed, these feature sets are largely independent from each other and can be composed in various ways. The conformance profiles are:

    (NOTE: technically, there should be a conformance clause for each conformance profile – so also addressed in this proposal).

    -----------------------

    M4- Line 3100: "In the absence of any claim to another externally-defined conformance profile" you can't control what other people will claim conformance to, you can only state what it means to comply with this specification. Suggest deleting or softening.

    Proposal: remove the sentence, and replace with:

    “It is possible for an MSH to conform to either one of these profiles, or to a combination of these.”

    -----------------------

    M5- Lines 3100-3102: says that "an implementation of this specification is expected to conform to either one or both of the conformance profiles defined here..." yet there are four profiles defined above! Please clarify.

    Proposal: addressed by proposal for M4.

    Jacques



  • 2.  RE: [ebxml-msg] Addressing comments from Martin C. : proposals

    Posted 10-20-2010 16:34
    
    
    
    
    
    
    
    
    
    
    
    


    From: Jacques R. Durand [mailto:JDurand@us.fujitsu.com]
    Sent: Wednesday, October 13, 2010 12:55 PM
    To: ebxml-msg@lists.oasis-open.org
    Subject: [ebxml-msg] Addressing comments from Martin C. : proposals

    Addressing comments from Martin Chapman (identified M1 – M5):

    -----------------------

    M1- Line 394: editorial - please spell out the acronym MSH (I think this is its first use in the doc).

    Proposal: add “MSH” entry in Terminology 2.2 (MSH is only casually defined in Core V3, but deserves a better definition status…)

    “MSH: Message Service Handler assumed here to be conforming to ebMS V3 Core specification as well as to features described in this specification (Part 2).”

    => could just use expansion initially and put (MSH) after.

    -----------------------

    M2- Line 408 and 490: talks about not modifying the SOAP message, I assume you mean soap headers and soap bodies - if so it might be worth saying this explicitly.

    Proposal: Clarify “without modifying the SOAP message or any attached payload à without modifying the SOAP message (SOAP envelope and its content) or any attached payload

    At least no modifications of signed data. If some headers were targeted at intermediaries, they might by soap processing rules get modified. Etc.

    -----------------------

    M3- Line 3093: "as these four feature sets are largely independent and composable in various ways."  This sentence doesn't parse - remove "as"?

    Proposal:

    Extend: This conformance clause is defining four conformance profiles:

    as

    This conformance section is defining four conformance profiles (or clauses) that address the four major feature sets specified here (multihop routing, message bundling, advanced interaction patterns, and message splitting). Indeed, these feature sets are largely independent from each other and can be composed in various ways. The conformance profiles are:

    (NOTE: technically, there should be a conformance clause for each conformance profile – so also addressed in this proposal).

    -----------------------

    M4- Line 3100: "In the absence of any claim to another externally-defined conformance profile" you can't control what other people will claim conformance to, you can only state what it means to comply with this specification. Suggest deleting or softening.

    Proposal: remove the sentence, and replace with:

    “It is possible for an MSH to conform to either one of these profiles, or to a combination of these.”

    Not certain that this replacement is that useful. And to address M5 wouldn’t you want to say “MSH conformance may be to exactly one of the profiles, or to any combination of profiles.”

    -----------------------

    M5- Lines 3100-3102: says that "an implementation of this specification is expected to conform to either one or both of the conformance profiles defined here..." yet there are four profiles defined above! Please clarify.

    Proposal: addressed by proposal for M4.

    Jacques



  • 3.  RE: [ebxml-msg] Addressing comments from Martin C. : final

    Posted 10-20-2010 19:01
    
    
    
    
    
    
    
    
    
    
    
    

    Final consensus inline on Martin’s comments : [final]

    -jacques

    From: Moberg Dale [mailto:dmoberg@axway.com]
    Sent: Wednesday, October 20, 2010 9:33 AM
    To: Jacques Durand; ebxml-msg@lists.oasis-open.org
    Subject: RE: [ebxml-msg] Addressing comments from Martin C. : proposals


    From: Jacques R. Durand [mailto:JDurand@us.fujitsu.com]
    Sent: Wednesday, October 13, 2010 12:55 PM
    To: ebxml-msg@lists.oasis-open.org
    Subject: [ebxml-msg] Addressing comments from Martin C. : proposals

    Addressing comments from Martin Chapman (identified M1 – M5):

    -----------------------

    M1- Line 394: editorial - please spell out the acronym MSH (I think this is its first use in the doc).

    Proposal: add “MSH” entry in Terminology 2.2 (MSH is only casually defined in Core V3, but deserves a better definition status…)

    “MSH: Message Service Handler assumed here to be conforming to ebMS V3 Core specification as well as to features described in this specification (Part 2).”

    => could just use expansion initially and put (MSH) after.

    [final] add an entry in2.2:

    “MSH: Message Service Handler assumed here to be conforming to ebMS V3 Core specification as well as to this specification (Part 2).”

    -----------------------

    M2- Line 408 and 490: talks about not modifying the SOAP message, I assume you mean soap headers and soap bodies - if so it might be worth saying this explicitly.

    Proposal: Clarify “without modifying the SOAP message or any attached payload à without modifying the SOAP message (SOAP envelope and its content) or any attached payload

    At least no modifications of signed data. If some headers were targeted at intermediaries, they might by soap processing rules get modified. Etc.

    [final] Clarify “without modifying the SOAP message or any attached payload à without modifying the SOAP message (SOAP envelope and its content) or any attached payload”. Add a note: “Signature integrity is a major reason for intermediaries to not alter SOAP content., when using security.”

    -----------------------

    M3- Line 3093: "as these four feature sets are largely independent and composable in various ways."  This sentence doesn't parse - remove "as"?

    Proposal:

    Extend: This conformance clause is defining four conformance profiles:

    as

    This conformance section is defining four conformance profiles (or clauses) that address the four major feature sets specified here (multihop routing, message bundling, advanced interaction patterns, and message splitting). Indeed, these feature sets are largely independent from each other and can be composed in various ways. The conformance profiles are:

    (NOTE: technically, there should be a conformance clause for each conformance profile – so also addressed in this proposal).

    [final] as above.

    -----------------------

    M4- Line 3100: "In the absence of any claim to another externally-defined conformance profile" you can't control what other people will claim conformance to, you can only state what it means to comply with this specification. Suggest deleting or softening.

    Proposal: remove the sentence, and replace with:

    “It is possible for an MSH to conform to either one of these profiles, or to a combination of these.”

    (Dale) Not certain that this replacement is that useful. And to address M5 wouldn’t you want to say “MSH conformance may be to exactly one of the profiles, or to any combination of profiles.”

    [final] use Dale wording.

    -----------------------

    M5- Lines 3100-3102: says that "an implementation of this specification is expected to conform to either one or both of the conformance profiles defined here..." yet there are four profiles defined above! Please clarify.

    Proposal: addressed by proposal for M4.

    [final] as proposed.

    Jacques