OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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). 


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?
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 Line numbering should start with 01:
This is a formatting problem. I will correct in the next draft.
BDXR-002, Section 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,

Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]