Some small comments below:

At 07:00 06/08/16, Arnt Gulbrandsen wrote:
>Spencer Dawkins writes:
>>> I was selected as General Area Review Team reviewer for this specification 
>>> (for background on Gen-ART, please see 
>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>
>> This is a re-review, my previous review was for 06, with Scott as 
>> shepherding AD, before IETF 65. I'm  reading the deltas from 06 (in the 
>> spirit of not finding new problems with previously-reviewed text).
>>
>> Summary: Again, nearly ready for publication as Proposed Standard, with some 
>> (new) items that do need to be addressed before publication.
>>
>> Thanks,
>>
>> Spencer
>>
>> 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.
>
>It is saying "Arnt cannot search and replace".
>
>    Collations provide a multi-protocol abstraction layer for comparison 
> functions so that these
>    comparison functions can be used in multiple protocols.
>
>(Maybe strike "layer". Not sure  yet. Must look at it when I'm 100% awake.)

I'd leave in layer, but take out the first "multi-protocol", to give
"Collations provide an abstraction layer for comparison functions so
that these comparison functions can be used in multiple protocols."

>> 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).
>
>It means: I'm not defining what these three return values are called, only 
>naming them so I can talk about them. If you implement this, you're free to 
>call them anything you want. You can use a C++ enum type, or -1/0/1, or 
>whatever.
>
>This rather awkward phrasing is a result of conflicting reviewer requests.
>
>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?

That would also be fine by me.

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

I didn't know that. If that's the case, we should provide a reference.
(we have RFC 2244 in the list of references, but no pointer to it
from 9.1, and we might want to make RFC 2244 normative).


Regards,     Martin.


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[EMAIL PROTECTED]     


_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art

Reply via email to