Re: [Geopriv] Web-based DHCP location encoder

From: Richard Barnes ^lt;rbarnes@bbn.com>
Date: Wed Apr 15 2009 - 19:05:36 EDT

It is correct behavior for an old client to reject an option encoded
with the new semantic -- otherwise it will get interpret the option
incorrectly. So providing a switch doesn't break backward compatibility
(the way you do encode the RFC 3825 semantic will be the same,
bit-for-bit, as before), but rather provides an orderly transition.

--Richard

Winterbottom, James wrote:
> I am not so sure that I understand how this will help.
> If the data is encoded using the BIS format then no old client is going
> to be any the wiser. In fact if you go around setting bit in fields that
> it doesn't understand, it is just as likely to go around rejecting the
> option as containing an error.
>
> My proposal would be that we don't do any indication. If you have a BIS
> client, great, you get a non-broken view of the world, and you treat all
> encodings as BIS. If you don't then if you get a BIS encoded option,
> then you are not really any worse off than if it wasn't encoded that
> way.
>
> So I am in opposition to providing a differentiator as you can't do this
> without breaking backward compatibility.
>
> Cheers
> James
>
>
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Richard Barnes
> Sent: Thursday, 16 April 2009 1:43 AM
> To: Thomson, Martin
> Cc: GEOPRIV
> Subject: Re: [Geopriv] Web-based DHCP location encoder
>
> Count me in with the folks who think there needs to be some sort of
> indicator as to which interpretation is being communicated. Attaching
> two different semantics to the exactly the same set of bits is the
> definition of non-interoperability.
>
> Looking at the 3825 format, it seems that the "datum" field is the only
> one where there's any chance of accommodating this indicator. Defining
> a single new datum is one way of doing it. Another way might be to
> split the field half: A 4-bit datum field (do we need more than 31
> data?) and 4 bits of flags (one for this, and three for later use).
>
> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
> | Datum | ---> | Flags | Datum |
> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
>
> If you add the caveat that all flags being zero indicates the use of the
>
> 3825 encoding, this remains bitwise backward-compatible with 3825 (since
>
> a 3825 server will set all flags to zero).
>
> --Richard
>
>
>
> Thomson, Martin wrote:
>> You'll note that the page clearly shows the two interpretations of RFC
> 3825. If you zoom to show the area described by the option and toggle
> the 3825bis checkbox, you'll see how these differ. In particular, note
> the difference when the point is near the edge of the box drawn using
> the (not bis) 3825 interpretation.
>> Richard: The encodings are the same, only the interpretation differs.
>> s/Alternate encoding/Alternative interpretation/
>>
>>> -----Original Message-----
>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>>> Behalf Of Richard Barnes
>>> Sent: Wednesday, 15 April 2009 8:58 AM
>>> To: 'GEOPRIV'
>>> Subject: [Geopriv] Web-based DHCP location encoder
>>>
>>> Hey all,
>>>
>>> FYI: The daunting thing about the DHCP location options (for me at
>>> least) has always been figuring out how to encode and decode them, so
>>> with some help from the loc-imp list, I've written a web-based
> encoder
>>> for the DHCP location options (RFC 3825 and 4776):
>>>
>>> <http://geopriv.dreamhosters.com/dhcloc/>
>>>
>>> (Actually, the decoding logic is there too, in the Javascript
> objects,
>>> but there's no GUI for it now.)
>>>
>>> Hopefully, this can be at least a basic tool to ease people into
>>> deploying this stuff. Please forward to anyone who might find this
>>> useful.
>>>
>>> Cheers,
>>> --Richard
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
> ------------------------------------------------------------------------
> ------------------------
>> This message is for the designated recipient only and may
>> contain privileged, proprietary, or otherwise private information.
>> If you have received it in error, please notify the sender
>> immediately and delete the original. Any unauthorized use of
>> this email is prohibited.
>>
> ------------------------------------------------------------------------
> ------------------------
>> [mf2]
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Wed, 15 Apr 2009 19:05:36 -0400

This archive was generated by hypermail 2.1.8 : Wed Apr 15 2009 - 19:05:47 EDT