[Geopriv] RE: [dhcwg] WGLC for draft-ietf-geopriv-dhcp-civil-04.txt

Henning:

    0 1 2 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OPTION_CIVIC_ADDRESS | option-len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Countrycode | what | elements ...
   | civic address elements |
   | ... |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Would usually be shown as:

    0 1 2 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OPTION_CIVIC_ADDRESS | option-len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Countrycode | what | .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
   . civic address elements .
   . ... .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(At least if we use RFC 3315 and 3633 as a guide.)

But, it's no big deal.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Friday, October 15, 2004 11:01 PM
> To: Bernie Volz
> Cc: hgs+simple@cs.columbia.edu; dhcwg@ietf.org; geopriv@ietf.org
> Subject: Re: [dhcwg] WGLC for draft-ietf-geopriv-dhcp-civil-04.txt
>
>
> Bernie Volz wrote:
> > Hi:
> >
> > Here's some quick review comments (these are mostly nits):
> >
> > - Clean up figure in 3.2?
>
> Can you clarify? I must be missing something obvious as to
> the defects
> of the figure...
>
> >
> > - Is there a minimum option length? Wouldn't it be at least 3 bytes
> > (to specify the country code and what)? Or, is at least one "civic
> > address element" also needed in which case the minimum
> length would be
> > 6?
>
> All elements are optional, so min. length would be 3 (just
> country code
> + what).
>
> >
> > - Is an IANA registry of the "what" values required? Or, do
> we believe
> > that the 3 values are all that will ever be needed (which is likely
> > the case)?
>
> I suspect that additional values are sufficiently unlikely
> that we can
> rely on a revised version of the document for extending the
> registry. I
> don't feel strongly about this; there used to be a time,
> maybe now past,
> where adding IANA registries was considered ill-advised.
>
> >
> > - For clarity, section 2's text:
>
> ...
>
> Fixed.
>
> >
> > And, similar adjustments should be made to section 5.
>
> Fixed.
>
> >
> > - Also, in section 2, shouldn't the text:
>
> > To provide multiple renderings, the server
> > ^^^^^^
> > repeats sequences of address elements, prefixing each
> with 'language'
> > and/or 'script' element (see Section 3.3). The language
> and script
>
> Indeed.
>
>
> >
> > - In section 3.1, it isn't immediately clear what the
> countrycode is
> > used for. I presume this is used to specify the mapping for
> the Catype
> > to a textual representation?
> >
> > Countrycode: The two-letter ISO 3166 country code in
> capital ASCII
> > letters, e.g., DE or US.
>
>
> Not really. This is just for space efficiency, since every
> civic address
> must contain a country code and since its length is fixed.
> There is no
> assumed mapping from country to language or script. I added a
> parenthesized explanation.
>
> >
> > - In section 6, specify that the initial allocations are
> provided in
> > Section 3.4 (I've found that IANA doesn't read the entire document,
> > just the IANA Considerations section so they'd need to be
> told about
> > the initial registry list or where to find it in the IANA
> > Considerations section.)
> >
>
> Reference added.
>
> Thanks for your comments!
>
> Henning
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 15 Oct 2004 23:54:45 -0400