Re: [ebxml-msg-comment] Comments on ebXML Messaging Services 3.0Conformance Profiles Public Review 01

[William Cox <wtcox@CoxSoftwareArchitects.com>]

Two additional comments.

[7]
Is this one normative or not? It apparently is not per the abstract,  Perhaps the mixed tables are intended as the conformance information, but there still needs to be a simple set of conformance clauses.

Thinking more about Conformance Profiles version 1.0 and the AS4 profile, I'm concerned that without rationale that one set of profiles is non-normative, and the other one one is? Why the difference? This should be clear in both documents, and conformance sections included.

[8] Editorial Major

I am puzzled that the editorial look-and-feel is very different between this and AS4 PRofile Version 1.0. Perhaps they could be better aligned, or if there's a convention that I'm missing, create a Typographical Conventions section is 1. (see SCA Assembly for one example, though an imperfect one).

Thanks!

bill
--

William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax

William Cox wrote:

4A42EBE7.7080608@CoxSoftwareArchitects.com" type="cite">I'm offering these comments on your specification as a member of the OASIS Technical Advisory Board.

Comment numbers in square brackets. References are to the PDF.

[1] Technical Lines 30 and references

I'm confused by normative references in a non-normative supplement. This could be explained better in the abstract and the introduction.

[2] Minor Editorial

Line 177 last characters are "RM V23" which should be "RM V2/3" to be consistent with the rest.
Line 178 change "excepts" to "except".
Line 228 delete "to be considered"
Line 237 delete "an already pervasive"
Table after line 253 Security, no bullet at second line.
Line 279 change "Fore" to "For".
Line 360 keep table heading with table.
Line 400 table V2 Reliability and others - why does font change in middle? I presume this is to match some format in another document, but it's confusing.

[3] Technical lines 201-203ff

The keyword MUST is used in ordinary text; also a normative requirement in a non-normative specification is confusing. RFC2119 does not require that the case be all upper. See lines 269, 411, and do a global search.

The nature of the apparent requirement e.g. Reliability in table after line 253 is diminished by not making clear the normative and required nature in keeping with the terminology. In the Security section of that table, bullet four, "attachments required." is also inconsistent with typical statements.

[4] Technical Line 412ff

This is well chosen - good job.

[5] Technical line 450-456
Spacing is strange; a URI is generally done in one of the shaded format.  AFter Line 455 add "but such profile is not defined here."

[6] Appendix A Table after 482

There is no guidance on how to define mandatory, optional etc. Should this have a reference?  If not, it should be better described as to what values and content.

--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax