> 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.
Of course. That's not the point.
The point is that if the spec says that the main content of the URI is to be
parsed according to a parameter, which will very often be absent, but when it is
present the content looks exactly the same as when it is present but does not
mean the same thing at all, then you're setting up an excellent interoperability
trap for naive implementers (you know, the usual kind).
The fact that implementers and their applications would be wrong is irrelevant.
Now, something more constructive:
Making the parameter mandatory, even maybe promoting it to a hierarchy element,
would probably result in better interoperability. How would people feel about this?
geo:wgs84:12.34,56.78
geo:foooo:12.34,56.78
Thanks,
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
