Tuesday, June 2, 2009

Re: [Geopriv] [VCARDDAV] The "geo" URI draft

At 11:33 AM -0700 6/2/09, Simon Perreault wrote:
>Ted Hardie wrote, on 2009-06-02 12:52:
>> As long as the other datum can be named in a parameter, there are no surprises;
>> if you see a triple with a named datum in that parameter, you use that datum
>> to understand the reference. Else, you use the default--WGS84.
>>
>> Is it simple? In the case where WGS84 is in use, yep it is as simple as the
>> geo URI as currently described. It is also more extensible--with the URI
>> syntax giving you the ability to get that extensibility while giving you
>> a useful default.
>
>The problem with this is that usually when an implementation doesn't understand
>a URI parameter, it will just ignore it and parse the rest of the URI and use it
>as if the parameter wasn't there. In these cases the content would parse as a
>WGS84 location but would be wrong.

If it sees a parameter that it doesn't understand, its behavior should be
controlled by the spec. Some parameters are safe to ignore; some should
cause you to throw an error. The spec should be crystal clear on which
this is. If it is not, it's a spec bug.

If the spec is clear about what you should do, and the app doesn't do it,
it is broken. There have been obvious cases where the common app
pool doesn't do what the spec says and a feature gets dropped as result.
But avoiding extensibility because that *might* happen seems to me
not value extensibility enough.

Sure, we can always mint a new URI scheme to get around the problem later,
but that gives you worse interoperability problems, at least as I see it.
regards,
Ted

PS. I removed the vcarddav list from the cc, after an exchange with one
of chairs; feel free to forward there if you feel it is still important to
cross-post. I would guess, however, that we should finish this discussion
in GEOPRIV.


>
>And I predict that most implementations of the "geo" URI will ignore the
>parameter and assume WGS84, given that the parameter will very rarely be present.
>
>This is an interoperability trap.
>
>Simon
>--
>STUN/TURN server --> http://numb.viagenie.ca
>Interplanetary news --> http://reeves.viagenie.ca
>vCard 4.0 --> http://www.vcarddav.org

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