Re: Consent

  A mandated-disclosure is one where the sender MUST deliver the
  location with tbd precision. A needed-disclosure is one where the
  sender SHOULD deliver the location with tbd precision. Is this
  moving in the right direction?

I think this drags in semantics that don't really fit. SHOULD has an
impression that it is better to comply, with the notion that there may
be good reasons why one doesn't. I'm uncomfortable with a protocol
document telling some computer/person that their location must be
revealed as a protocol issue - this both seems unreasonable and
crosses the no-contortions-for-laws line.

needed-disclosure has a different sense from SHOULD - it's about
policy, and independent of implementations. In this case, a service
provider says "if you don't provide a location, I won't give you
service". Whether to provide a location and get the service is a
per-user/agent per-service policy choice (perhaps evaluated at every
use). Thus, this is squarely in the realm of policy.

So, perhaps the request for location should contain some sort of
information that specifies what is required to obtain the service.
I believe that this isn't all that different from a service that
requires a name/address/credit card in a web form, except that the
requirements statement isn't intended to be machine-parseable.

But even in the 'needed' case, there is some fuzz in what is
'necessary'. I have used a number of geographic search services, and
almost never given the right location. Usually I pick some round
number that is more or less close, and some wide enough radius, and
then filter the results on my end. Some sort of protocol support to
make this sort of behavior easier could be helpful, but this gets into
how the response is encoded, and that seems out of the charter's scope.

Another issue I have with 'mandated-disclosure' being equated to MUST
is that it commingles legal issues and protocol issues. MUST is about
ensuring interoperability, and sending location is a policy/legal
issue.
To reconcile these, location objects should have one or more
distinguished values representing "location not available", perhaps in
various flavors.

A legal requirement to send location on emergency calls can be viewed
not as a protocol issue, but a requirement for policy configuration to
be done a certain way. The protocol can still allow the
(IETF-viewpoint :-) appropriate level of user control.
Corporate-manufactured handsets in the US would probably then have a
'911 gets location no matter what' policy in ROM.

That said, it seems reasonable to have some protocol support for
policy configuration, in the spirit of a CA for 911-like answering
points which have a legal requirement for location delivery. Then, a
handset could easily be configured with "deliver location to 911-like
places for which there is a legal requirement to do so" policy
hard-coded. This raises issue of predelivery of such things so that
they'll be in place when services are needed and there isn't time to
fetch certs. All of this would be optional in the protocol spec; it's
merely a way to express policy. (My sense of the IETF/legal situation
is that it is ok to provide support for various possible policies in a
policy negotiation system, but not to contort a protocol or do
something technicall broken to meet some particular law. So this
seems ok.)

Perhaps policy support capable of expressing policies like the above
should be MUST (with the caveat that there there should
confidentiality and integrity protection on information in transit).

        Greg Troxel <gdt@ir.bbn.com>
Received on Thu Aug 30 10:21:41 2001