Tuesday, June 23, 2009

Re: [Geopriv] Issue: version "negotiation"

At 09:16 AM 6/23/2009, Bernard Aboba wrote:
> > >There are a number of potential cases here:
> > >
> > >a. Legacy (v0) client speaking to v1 server.
> > >b. Legacy (v0) client speaking to v0 server.
> > >c. V1 client speaking to v0 server.
> > >d. V1 client speaking to v1 server.
> > >
> > >
> > >c. Do we understand how existing v0 client implementations will
> > >behave if they receive a v1 packet from a server?
> >
> > today - no, this is not completely predictable.
> >
> > Part of 3825bis will add text to give guidance on the desired
> > behavior for each scenario.
>
>By "unpredictable" do you mean "untested" or "could vary
>between implementations"?

since there is no guidance in 3825 on what to do if a v0 client
receives a datum it does not understand, I don't believe we can state
with certainty what the outcome would be.

That said, (somewhat reaching) common sense says a v0 client
receiving a datum value that it does not understand (anything above
datum value=3), the client will most likely discard the Option.

The only exception I can think of is that an implementation may
default back to WGS84 (4326 or 4979), though nothing in 3825 says to
do this. This may be an implementation specific "common sense"
approach that wasn't documented openly.


>In the case of .11 implementations, the code for the v0
>client could be present in firmware or a kernel mode
>driver. That implies that mis-behavior can have serious
>consequences.

There has to be "what to do if I (the client) receive a datum > 3...
I would assume that behavior is what happens, though there is no
known documented open behavior (other than likely to discard the
Option in total).


>We can address cases c and d in RFC 3825bis, and case b
>is inherited from RFC 3825.
>
>Do we have the same freedom with respect to case a?

for (a), if the server sends a v1 Option, then we're exactly where we
are now if a v0 server sends a Option value with a datum > 3. At
that point, datum=4 is the same as datum=65 or 129 or whatever.

BTW - it's also the same behavior as a v0 client that didn't
implement anything but datum=1 (WGS84). The result is the same, I believe.


>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv