Cc'ers: Just Hit Delete. Spencer: This lists what I change in -14 and what not.
Spencer Dawkins writes:
Review Comments: 2.2. Purpose Collations abstraction layer for comparison functions so that these comparison functions can be used in multiple protocols. I am just barely able to parse this sentence so that it's not a sentence fragment. I think the problem is that "functions" is being used as a verb and as a noun in the same sentence. I saw later in the document that you had changed "function"-the-noun to "operation", so should be easy to fix. But this isn't an editorial comment, because I'm not sure what the sentence is saying.
Fixed. There were missing words.
4.2.2. Equality ... In this specification, the return values of the equality test are called "match", "no-match" and "undefined". This is not a specification, merely a choice of phrasing. What does the last sentence mean? (Brian Carpenter asked me, so he doesn't know, either).
I changed it as discussed.
6. Use by Existing Protocols ... IMAP [16] also collates, although that is explicit only when the COMPARATOR [18] extension is used. The built-in IMAP substring operation and the ordering provided by the SORT [17] extension may not meet the requirements made in this document. Other protocols may be in a similar position. In IMAP, the default collation is i;ascii-casemap, because its operations most closely resembles IMAP's built-in operations. EDITORIAL: I'm guessing that the previous paragraph should be moved up one?
Not moved.
At the very least, I'm confused because I'm not sure if the top paragraph in this extract describes the differences between i;ascii-casemap and IMAP's built-in operations or is talking about something else.
New text is as suggested by you: «In IMAP, the default collation is i;ascii-casemap, because its operations are understood to match's IMAP's built-in operations.»
9.1.1. ASCII Numeric Collation Description The "i;ascii-numeric" collation is a simple collation intended for use with arbitrary sized unsigned decimal integer numbers stored as octet strings. US-ASCII digits (0x30 to 0x39) represent digits of the numbers. Before converting from string to integer, the input string is truncated at the first non-digit character. All input is valid; strings which do not start with a digit represent positive infinity. Is it obvious to everyone except me that leading zeros are ignored? The examples giving a little further down say so - is making this point in examples normative enough? 9.2.1. ASCII Casemap Collation Description ... The i;ascii-casemap collation is well suited to to use with many internet protocols and computer languages. Use with natural language is often inappropriate: even though the collation apparently supports languages such as Italian and English, in real-world use it tends to stumble over words such as "naive", names such as "Llwyd", people and place names containing non-ASCII, euro and pound sterling symbols, quotation marks, dashes/hyphens, etc. OK, this may be inadvertantly funny - are "naive" and "Llwyd" supposed to include a non-ascii character, or is that sentence saying something else? (Welcome to the world of the RFC Editor)
Changed as per Lisa's suggestion.
13. Open Issues ... adding a note to the RFC editor to possibly replace the 3066 reference From Brian: Surely this needs to be done? From Spencer: I'm thinking that the "checking the SP SP "1" SP SP string for correctness" also needs to be done pretty soon :-0
I don't think I'm going to use xml2rfc again. I hate seeing "In section 3.5" when I don't see 3.5 in the source. Having to redo this spacery time and time again is also painful. Arnt _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
