Subject: [Geopriv] Re: Review of civic ID for Geopriv WG

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Sep 2004 15:24:26 -0400

Sorry for the delay in responding to your comments. Some of these had 
been fixed in a revision that didn't make the cut-off.

James M. Polk wrote:
> The following is my review of the ID:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-03.txt
> 
> general comment, the term "Location Configuration Information (LCI)" is 
> not used anywhere in this document, something 3825 had to spell out.

It's now used in the abstract now at 
http://www.cs.columbia.edu/sip/draft/civic/draft-ietf-geopriv-dhcp-civil-04.html

> 
> - In section 2, 3rd paragraph, 1st sentence starts with:
> 
> "A related draft [13]..."
> 
> this is an RFC now [3825], meaning the references section needs to be 
> changed also

fixed.

> 
> - in section 3.1, under the "what" paragraph, it states:
> 
> "Options (1) and (2) SHOULD NOT be used..."
> 
> and yet the Id just stated in the previous sentence Option (2) SHOULD be 
> used. I believe the options that should not be used are (0) and (1) in 
> this sentence above.

Fixed.

> 
> - in section 3.3, under CAvalue, it is stated UTF-8 is to be used. This 
> is consistent with RFC 2277, but that reference gives a concession to 
> exceptions with "really good reasons". I think a double byte character 
> set from our friends in Asia c/w/should be allowed to be such an 
> exception - especially since their languages are used as a reference in 
> this doc. So I believe UTF-8 SHOULD be used, unless procedures under 
> 2277 allow for UTF-16 to be used. If this is the case, there needs to be 
> a means of identifying this usage somewhere

Here I'm confused by your comment. UTF-16 and UTF-8 just encode Unicode; 
in other words, every character that can be expressed in UTF-16 can also 
be expressed at UTF-8, with no loss of information.

> 
> - on page 11, the 3rd paragraph mentions CAvalue 25 as being "type of 
> place", when in fact I believe this is CAvalue 29.

Oops; the danger of having multiple references... Fixed.

> 
> - section 4, the example, I have a specific concern that any CAtype 
> field can be in any order, yet it is allowed to have multiple languages 
> in the multiple responses of a single DHCP packet. To that end, I state 
> the following:
> 
>         Any CAtype can be in any order, and yet there will end up being 
> examples of a field in one language being misunderstood in another 
> language - if a single packet can contain many languages of CAvalues. I 
> think it should be at least stated as being required to group each 
> language set of CAtype fields together, without the need to repeat 
> redundant CAvalues if another language has the same entry.

If I understand you correctly, you'd like to suggest that elements 
grouped by common language. I agree since this would be more efficient, 
but it should not affect correctness. A receiver must be able to deal 
with languages that "shift" for every element (which should not be 
hard). I've added wording to the 'in any order' paragraph.

> 
> With these considerations/corrections made, this ID is ready to go to 
> WGLC as is

Thanks for your review.

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Sep 2004 15:05:43 -0500

At 03:24 PM 9/28/2004 -0400, Henning Schulzrinne wrote:
>Sorry for the delay in responding to your comments. Some of these had been 
>fixed in a revision that didn't make the cut-off.
>
>James M. Polk wrote:
>
>>- section 4, the example, I have a specific concern that any CAtype field 
>>can be in any order, yet it is allowed to have multiple languages in the 
>>multiple responses of a single DHCP packet. To that end, I state the following:
>If I understand you correctly, you'd like to suggest that elements grouped 
>by common language. I agree since this would be more efficient, but it 
>should not affect correctness.

you don't believe this can happen when you state redundant fields should 
not be included when including more than one "set" or "group" within the 
same packet can be present?

It at least seemed like it could get confusing - but maybe it's just me 
(the way I read it), but this is as much a way of debugging it as anything.

>A receiver must be able to deal with languages that "shift" for every 
>element (which should not be hard). I've added wording to the 'in any 
>order' paragraph.
>

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Sep 2004 19:52:49 -0400

>> grouped by common language. I agree since this would be more 
>> efficient, but it should not affect correctness.
> 
> 

In pseudo-code, this is pretty simple:

while (e = next element) {
   switch (CAvalue) {
   case LANG:
     lang = value;
     break;
   case SCRIPT:
     script = value;
     break;
   default:
     option(value, lang, script);
}}