Arnt Gulbrandsen wrote:
Spencer Dawkins writes:
I could say «The return values of the equality test are called "match",
"no-match" and "undefined" in this document.» Would that be clear
enough?
Spencer-Reply: That would work for me - I know Brian needed help, too,
and he's the one that needs to be happy. But we're within an RFC
Editor note of finished on this.
I would wish more readers than just Brian to understand the document ;)
Brian?
I can understand the new sentence :-)
Brian
5.2. Operations
...
Although the collation's substring function provides a list of
matches, a protocol need not provide all that to the client. It may
provide only the first matching substring, or even just the
information that the substring search matched.
Hmmm. I am trying to remember that you're not defining a protocol,
only describing what protocols do and don't do, but I'm trying to
read this from the application's perspective, and having a hard time
understanding how (for example) an application that is trying to
display what is matching responds when the protocol only provides an
indication that something matched. You may say this is what the
protocol developers are supposed to worry about ("if you think
applications will want to display what matches, you'd better define
the protocol so that this information is returned"), and that's OK.
Exactly.
Some current-day protocols are defined such that 'x contains y'
returns true/false. Servers implementing such protocols should still
be able to use collations.
Spencer-reply: If you stuck "In this way, servers can use collations
to support protocols that are defined such that 'x contains y' returns
true-false." at the end of the paragraph, I'd "get it" without help.
Fine, except that I'll try to find some wording that avoids 'contains'.
Reviewer request, some months ago. "is a substring of", perhaps.
In IMAP, the default collation is i;ascii-casemap, because its
operations most closely resembles IMAP's built-in operations.
...
Spencer-reply: Again, your explanation helped a lot and I'd like to
hijack it into the document. Something like "In IMAP, the default
collation is i;ascii-casemap, since its operations are understood to
match IMAP's built-in operations."?
Fine.
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?
It's specified in 2244, so I don't think it's very important. This
document merely registers a collation which has been specified for a
decade and implemented in many products.
Spencer-reply: ack.
But maybe, just maybe, section 9 needs to be clarified as such:
This section describes an initial set of collations for the collation
registry. These collations were originally specied in RFC 2244.
Spencer-reply: I guess my point was that this was extremely subtle for
those of us who don't work with i18n comparison all day long. Perhaps
'Welsh names such as "L1wyd", when the Welsh consider "ll" a separate
letter and sort it between "1" and "m"'? But you're going to have to
figure out how to get "naïve" into an RFC... Perhaps your AD can step
in front of this speeding bullet?
Lisa suggested rewording to use bullet points and some parenthetical
elaboration. That's ok with me. I'll look at some RFCs and make the
bullets look the conventional way.
If the RFC editor quibbles about naïve, it can also be deleted. There
are enough points in that list that any single one can be deleted
without harm. People are just as easily persuaded by five reasons as by
six.
Arnt
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
