Re: Comments on 3023bis [all editorial]

Paul Grosso writes:

> [Comment on new text]
> Section 3.1, Encoding considerations, first (new) sentence.
>
> There is a use of the word "may" that is not
> capitalized.  I don't know if this is a 2119 use and
> if so if it should be capitalized.

Changed to 'can', the usual compromise in such cases.

>> Section 3.1, Interoperability considerations (page 7)
>>
>> There is a use of the word "recommended" that is not
>> capitalized.  I don't know if this is a 2119 use and
>> if so if it should be capitalized.

Reworded to avoid the word.

>> Section 3.1, Change controller (page 8) reads:
>>
>>  The XML specification is a work product of the
>>  World Wide Web Consortium's XML Working Group
>>
>> If we were referring to the February 1998 version, the WG at
>> that time was called the XML Working Group (though the document
>> itself says the spec was a product of the XML Activity).  But
>> given that the reference to the XML spec is to the 5th Edition,
>> and that we are talking about the (supposedly current) change
>> controller, I think you want to refer to the "XML Core Working
>> Group" here.

Done.

>> Section 5 Fragment Identifiers, second para, penultimate
>> sentence (page 12) reads in part:
>>
>>  conformant applications MUST
>>  interpret such fragment identifiers as designating that part of the
>>  retrieved representation specified by [XPointerFramework] and
>>  whatever other specifications define any XPointer schemes used.
>>
>> Maybe it's just me, but I cannot parse the last part of that sentence.
>
> Assuming I'm guessing correctly, perhaps the following
> would be a bit clearer:
>
>  ...and whatever other specifications that define any of the
>  XPointer schemes that are used.

Reworded.

> [Comment on new text]
> Section 7. XML Versions, 2nd para, last sentence
>
> There is a use of the word "may" that is not capitalized.

reworded

> Section 9 Examples, 2nd para, end of parenthesized text reads:
>
>   media types which to not enable its use
>
> Presumably, s/to/do/

Done (silently)

>> Section 11, Security Considerations, first para, second
>> sentence would be easier to parse with appropriately
>> added punctuation, to wit:
>>
>>  These entities may contain--and recipients may
>>  permit--explicit system level commands to be
>>  executed while processing the data.

Already has commas, which I think actually suits the semantics better
than dashes. . .

>> Section 11, Security Considerations, very last "sentence"
>> is not a sentence and does not contain a period (full stop).
>>
>> Perhaps insert at the start of the parenthesized text the
>> phrase "Consider the case where" and insert a period before
>> the close parenthesis.

Done.

>> Section 12.1 Normative References, the [XptrReg] (last) reference.
>
> And now also the [XPtrRegPolicy] reference.
>
>>
>> This refers to the web page
>> http://www.w3.org/2005/04/xpointer-schemes/
>> which is not an RFC, standard, or W3C Recommendation,
>> so I question if this can be a normative reference.
>>
>> What are the rules for what can be a normative reference
>> in an IETF RFC?  Perhaps this should be moved to the
>> informative references section.

I'll let the IETF rule on this one.  My view is that the way these are
used in the text determines whether they are normative or not, and
they appear in MUST/SHOULD language sentences, so they have to be
normative.

>> Appendix B. Changes from RFC 3023, second para, first sentence
>>
>> missing close paren

Done.

Thanks -- these changes will appear in the official -4 versions to be
published shortly.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

Received on Monday, 4 November 2013 12:36:10 UTC