Subject: RE: provided-by too vague (was Re: [Geopriv] Offered Text into PI DF-LO ID)

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 25 Mar 2004 14:30:51 -0500

I think we feel that a URI COULD provide a lot of data, but even if
it was a plain old web page with some information on it, that might be
enough.  To try to build an extensible mechanism in PIDF-LO is going
the wrong way, I think.  If NENA wants to develop an XML format,
and some carriers in North America or elsewhere choose to implement
it, or even get forced to by FCC regulation, that's not the IETF's
business.  Making interoperable specifications is, and a URI,
to me, is an acceptable, minimal answer, that has a quantifiable
affect on privacy, that can be, and has been explained in the text.
I think that making some extensible mechanism makes it worse, not
better.

It also solves the problem now, which is always a virtue if you
understand the consequences.  I think we do.

Brian

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Thursday, March 25, 2004 1:22 PM
> To: James M. Polk
> Cc: Jon Peterson; [email-masked]; Abbott, Nadine B.; Henning
> Schulzrinne
> Subject: provided-by too vague (was Re: [Geopriv] Offered Text into
> PIDF-LO ID)
> 
> 
> Instead of responding to each person, I think it would be better if I 
> just attempted a summary.
> 
> What I see here is that all the requirements for this, especially 
> <provided-by>, have not been fully baked (Nadine said as much in her 
> email).  So the general thought is that a URI will be used as an 
> extension mechanism for that future functionality because it leaves 
> open the possibility for almost anything.  If you think this a good 
> thing, I invite you to step into the world of RFC 954 (apropos when 
> talking about privacy).
> 
> As John has pointed out, a huge downside is the lazy implementer.  I 
> actually wouldn't call them lazy.  A better description is that they 
> are not fully aware of the ramifications of simply inserting 
> a URI with 
> regard to impact on privacy.  I do not think it is far fetched to 
> envision an implementation that always inserts an http URI for the 
> hostname of the location server (or even an http URI to the 
> vendor as a 
> misinterpretation of "provided-by").  Even worse, what about 
> the techie 
> in the field who must provide this information?
> 
> There are certainly better mechanisms available for 
> extensibility, the 
> best candidate being the syntax defining PIDF-LO itself, XML.
> 
> So if NENA wants NENA identifiers, why not:
> 
>    <provided-by> <nena> abc-123 </nena> </provided-by>
> 
> This makes it much clearer what information is being passed, what 
> information the implementation needs to have, and what 
> information the 
> server operator needs to provide.  Leaving this field up to the 
> imagination of the vendor or the tech guy in the field only invites 
> trouble and will likely not provide an ECC with useful information.
> 
> -andy
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv