Re: GEOPRIV and the W3C Geolocation API

On the contrary, the point of APIs being compatible with RFCs is to 
minimize "transcoding" between two standards.  The API specifies the 
formats and interactions within a host, and the RFC specifies what 
formats and interactions on the wire.

If it's going to use network services, the code that implements the API 
has to think in API terms on one side and in RFC terms on the other.  If 
these are dramatically different (say, if the email API wanted addresses 
as images for anti-spam purposes), then the API has to translate.  The 
point of making the API compatible with the RFC is to make this 
translation easy.

If you know that you're going to have code that has a particular 
protocol on the back end, then having APIs that match up well against 
the corresponding RFCs minimizes the risk of mis-interpretation and 
makes interoperability easier.  In this case, given that GEOPRIV 
protocols are the Internet standard protocols for a host to acquire 
location, it's very likely that code will want to use them on the back 
end, so it makes sense for the API to be compatible with them.

--Richard


Aaron Boodman wrote:
> On Tue, Nov 11, 2008 at 6:42 AM, Richard Barnes <rbarnes@bbn.com> wrote:
>> Actually, this doesn't seem odd to me at all.  If you were designing API
>>  for sending email, you would definitely want it to be compatible with  RFC
>> 2821 (SMTP) and RFC 2822 (E-mail formats).  If you were designing an API for
>> getting information over HTTP, you would want it to be compatible with RFC
>> 2616.  (Most such APIs have the above properties!) It doesn't seem that much
>> of a stretch to say that it would be good for a Geolocation API be
>> compatible with RFC 4119.
> 
> The goal in those cases would probably be to be compatible with
> existing deployed systems, not to be compatible with the various RFCs.
> The fact that those systems happen to mostly implement published
> standards makes it more convenient to achieve compatibility, but
> compatibility is the goal.
> 
> - a
> 
>

Received on Tuesday, 11 November 2008 18:20:08 UTC