Subject: [Geopriv] <provided-by>

From: Ted Hardie <[email-masked]>
Date: Thu, 25 Mar 2004 11:44:17 -0800

I join Andy in worrying that the current definition of <provided-by>
is too vague to be a good match for this intended use case.  As it
stands now, allowing any URI here is going to result in cases where
there is no useful data about the validating party at all, and in many
others cases the useful data could not be dereferenced in a useful
amount of time.  A mailto: URI, for example, might get you to
a responsible party, but I'd hate to count on it for the 5 minute
response time that gets you on the news.  The IESG has kicked
back a number of PKIX documents recently where the specification
named an element as a URI with no indication of what scheme
would be used, and I think the same considerations here.  To
get real interoperability, you need a tighter specification of what
is allowed.

I don't doubt that this is useful, and there are a number of ways
to make it map either onto existing systems (a URN:nena nid, for
example) or onto very useful bits of contact information (heck,
an E.164 number might be nice).  But I really don't see the
requirement that this be in the baseline spec.  A short, focused
document that describes this mechanism as an extension seems
like a more useful way to go here, as it will be easier to focus
on a single use case.  PIDF-LO is the critical piece of work onto
which that use case can build, and we need to get it out; delaying
it for this is not helping us answer the use case--it's just creating
resistance as we try to understand how it fits into every other
use case in which pidf-lo will be used.

I encourage everyone who is focused on getting this into the baseline
spec to consider the real costs and consequences of that, and whether
it is truly the right place to frame the debate.

			regards,
				Ted Hardie

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