Hi Sander
Thanks for the observation and I agree with you. The “<?xml” opening tag mentioned in 3.3 is the XML declaration, not the doc type declaration. I’ll be submitting an updated working draft
today implementing your comment and the first comment from Juan Carlos (regarding PEM certificate formatting).
Best regards,
Kenneth
From:
<
bdxr@lists.oasis-open.org> on behalf of Sander Fieten <
sander@chasquis-consulting.com>
Date: Monday, June 6, 2016 at 8:28 AM
To: "bdxr@lists.oasis-open.org" <
bdxr@lists.oasis-open.org>
Subject: Re: [bdxr] SMP comment resolution
Hi all,
while going through the issues and proposed solutions I noticed that there is probably another error in section 3.3 besides the incorrect case sensitive remark on the character encoding. The second sentence of §3.3 states that the returned
XML document MUST contain a document type declaration. I however think that this should be the XML declaration as the doctype declaration is the ' <!DOCTYPE’ “tag” (see section 2.8 of the XML specification ).
Regards
Sander
On 27 May 2016, at 07:07, Kenneth Bengtsson <
kbengtsson@efact.pe > wrote:
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