Re: [bdxr] SMP comment resolution

[Kenneth Bengtsson <kbengtsson@efact.pe>]

Dear all

 

I’m reviewing some of the comments that we went through on Wednesday, and realize that there’s a wrong assumption in the proposed resolution for PEPPOL-012 (“Section 2.4.6.3: Add that documents where the namespace URI contains «::» MUST NOT be referenced using SMP”). I was reading in the wrong part of the SMP spec (XML representation of document identifiers) when assuming this was a PEPPOL specific rule. The comment is in fact related to the URL representation of document identifiers, where the character sequence “::” is indeed part of the parsing rules of the SMP spec. A document identifier containing the characters “::” would actually make parsing of the URL impossible.

 

I recommend that we accept the comment and add a note in the spec that document identifiers MUST NOT contain “::”. I can draft the note.

 

Best regards,

 

Kenneth

 

 

 

From: <bdxr@lists.oasis-open.org> on behalf of Kenneth Bengtsson <kbengtsson@efact.pe>
Date: Friday, May 27, 2016 at 12:07 AM
To: "bdxr@lists.oasis-open.org" <bdxr@lists.oasis-open.org>
Subject: [bdxr] SMP comment resolution

 

Dear all

 

As agreed at this weeks meeting I have continued working through the comments received to the SMP 1.0 public review, and made the recommendations for comment resolution below. Your feedback is very much appreciated so that I can start drafting a comment resolution log and an updated draft specification. I would especially appreciate any opinions on comments PEPPOL-016 and PEPPOL-017:

 

PEPPOL-013, Section 3.2 (on HTTP redirection): Add a short note for the HTTP verb HEAD:

I was looking into this and found the following in the HTTP 1.1 spec (http://www.ietf.org/rfc/rfc2616.txt): “The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request”.

 

In the SMP spec section 3.2 on the subject of redirection, we are saying that an SMP service “SHOULD NOT use redirection in the manner indicated by the HTTP 3xx codes”. Earlier in the section 3.2, the SMP spec says that an SMP service MUST support HTTP 1.1.

 

So following that logic, since 1) SMP says that an SMP service SHOULD NOT send HTTP 3xx redirection codes to an HTTP GET method, 2) HTTP 1.1 says that a HEAD request SHOULD receive identical headers to a GET request, and 3) SMP says that an SMP service MUST support HTTP 1.1, then I believe that the subject of the HEAD method is already implicitly dealt with in the SMP spec. We could add a note saying that an HTTP HEAD request must be responded to in accordance with HTTP 1.1, but that would be redundant since we already require HTTP 1.1 compliance. My recommendation is therefore that no change is needed in SMP. I welcome any alternative viewpoints.

 

PEPPOL-014, Section 3.3: Content of the encoding attribute (UTF-8) should not be case sensitive per say but should follow XML spec:

I agree with the comment and recommend that we remove the text “Please observe that the content of the encoding attribute is case sensitive” from section 3.3 of the SMP specification.

 

PEPPOL-015, XML schema: Remove intermediate elements “ProcessList” and “ServiceEndppointList” in version 2.0 to simplify schema:

I recommend that same resolution as in the PEPPOL-010 and refer further review and considerations of the comment for the next major release of SMP.

 

PEPPOL-016, XML schema: http://www.w3.org/2005/08/addressing is not required:

Any opinions?

 

PEPPOL-017, XML schema: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd is not required:

Any opinions?

 

PEPPOL-018, Grammatical/editorial comments not encompassed in the above (see: https://www.oasis-open.org/committees/document.php?document_id=58188&wg_abbrev=bdxr):

This is solely formatting, spelling and other trivial error correction. I’m personally willing to accept all corrections. Anyone else?

 

ATO-001, Examples should use the more broadly useful ebCore Party ID for party IDs, instead of the PEPPOL specific "busdox-actorid-upis":

I think this is a very valid observation, and I recommend that we add examples of using ebCore Party IDs in addition to (not replacing) the PEPPOL examples. I can make a draft if agreed upon.

 

BDXR-001, Section 2.3.3.2: Line numbering should start with 01:

This is a formatting problem. I will correct in the next draft.

 

BDXR-002, Section 2.4.7.1: HTML and PDF versions contain line number "04" (normative editable version does not have line numbering):

I’m assuming this has something to do with the way alternative formats are rendered from the original Word document. I will contact Chet to see if there’s anything in the formatting of the Word document we can change to avoid this happening.

 

BDXR-003, Section 3.2: Hanging paragraph:

When adding section 3.2.1 on HTTP caching we unintendedly created a hanging paragraph of the preceding text. I recommend that the text preceding the section on HTTP caching becomes section 3.2.1, so that the HTTP caching section becomes 3.2.2 and we avoid the hanging paragraph.

 

BDXR-004, Section 3.2.1: Samples in HTML and PDF versions contain line numbering "05" and "06" (normative editable version does not have line numbering):

Same as BDXR-002. I will contact Chet.

 

BDXR-005, Section 3.4: Hanging paragraph:

This section has a hanging paragraph consisting of the text preceding section 3.4.1 (Using identifiers in the REST Resource URLs). I recommend that we renumber 3.4.1 to 3.4.2, and let the preceding text become 3.4.1 to avoid the hanging paragraph.

 

BDXR-006, Appendix C3: Line numbering should start with 01:

This is another formatting error. I will correct in the next draft.

 

BDXR-007, Appendix D should be labelled "non-normative" for consistency:

This is the appendix listing the changes done to the various working drafts of SMP 1.0. I recommend that we move this appendix into a separate working document and remove it entirely from the SMP spec. Since the future SMP 1.0 Committee Specification will at some point become a candidate OASIS standard with the objective of publishing an SMP 1.0 OASIS standard, the changes made through various unpublished working drafts become irrelevant to the specification and do not add any value.

 

Best regards,

 

Kenneth