RE: Requirements Document

> >There certainly is scope for dealing with agents that are
> across the wire
> >from the sender (I send location to a server that authenticates and
> >provides my location to others on my behalf).
>
> There are senders and receivers. What you are talking about is a
> receiver who may become a sender, and calling this receiver-sender an
> "agent". I'm just clarifying terminology.
Yes, you have interpreted what I meant correctly.

>
> > I want the object to be able to be used in such a circumstance.
> >The issues of how the delegation is done, and how the authentication
> >between the ultimate receiver and my agent is, I think, also beyond
> >any strict requirement.
>
> I disagree. The delegation rights for the information must be
> encoded in the location message.
I agree that it COULD be, for some uses, although I suspect that
in fact the delegation for the vast majority of the cases is
in fact more static, and received out of band. With respect
to our work, I can see writing up some requirements for a
such a case as an example, but I would be against mandating the
mechanism. Thus my opposition to a strict requirement.

We can say something like, "where it is appropriate, delegation
of rights could be sent with the location message. In such a
case, protocol designers may consider the following requirements."

What you can't do is state absolute requirements, because they vary
greatly by use case.
>
> > My agent could receive my delegation by out-of-band means. It
> >could authenticate by out-of-band means.
>
> I suppose it could. But why is that desirable? Even if it is, we
> still need a way to change the delegation privileges in-band. We
> don't want to force people to go out-of-band to change the delegation
> privileges. That would be inconvenient in many circumstances.
It is desirable because the UI for the end device may be much less
convenient to allow a full and complete disclosure of when and
under what circumstances delegation is permitted. A much more
reasonable scenario is that you sign up for a service which has
a website where your contract is spelled out. You may have a number
of controls, best managed by a desktop UI. You make your choices,
come to agreement, and then your end device makes reports to the service
and the service does the delegation.

I don't want to force anything on anybody. I want to make services
available.
I want options, not restrictions. I'll be very happy to accommodate
any of the mechanisms you want to see, as long as every one of them
is optional to implement.
>
> > The requirements document can say that the user must delegate and
> >define the scope, lifetime and privileges of such delegation, but it
> >can't specify what limits to such delegation there might be, nor the
> >mechanism that it might use.
>
> It can be a requirement that there must be a mechanism for
> delegation, and that mechanism transmits the scope, lifetime and
> privileges of the delegation.
No, no, no. There can be an OPTION for delegation. There are many
systems where delegation is not appropriate at all. You can say
IF there is a delegation then the delegation mechanism must have
a means to define scope, lifetime and privileges. You can say
IF the delegation mechanism is dynamically changeable, then
there COULD be a mechanism that alters the scope, lifetime and
privileges with the location report. The delegation could be
done by its own message exchange for example. You cannot mandate
mechanisms in a protocol you aren't designing.

In my first use, there is both law and service agreement restrictions
on what can be changed. If the carrier offers you service, may do so
on condition that you agree to allow location information to be
sent for an emergency call. In this case, there is implied
delegation - the PSAP can give your location to the emergency responder.
You cannot control this. There will be no delegation information
in the sip messaging that reveals location. There will be no
explicit consent. There will be no UI. You can choose to not
place an emergency call (actually, I believe if you call the
police/fire/ambulance using the normal telephone numbers, none of
the legal or contractual obligations to provide location apply, it's
only if you call using 911/112/...).

Brian
 
Received on Thu Aug 23 09:20:25 2001