RE: Requirements Document

At 8:29 AM -0400 8/24/01, Brian Rosen wrote:
>I wrote this before I saw your mail on your interpretation
>of the charter. So, from your point of view, this is mostly
>meaningless, but I think you are incorrect, so I offer it anyway.

We're struggling to come to a common understanding. That isn't
necessarily easy, and I apologize for letting my frustration show.

>
>I don't really understand how you intend to accomplish our
>goals. We are defining the requirements for an object.

Yes, that's part one.

> We aren't defining a protocol,

No, this is mistaken. We have to define a protocol to carry the
object. Recall that is one of the milestones for this WG. There are
a couple of different ways to accomplish this. a) We could create a
brand spanking new language to deliver the object from sender to
receiver. b) We could take an existing protocol -- like SIP or HTTP
-- and propose extensions which enable them to carry the object. "b"
is likely the more preferable route. I've been down the "a" road
before, and it's a bumpy ride.

> and FOR SURE, we are going to
>use this object in existing protocols with existing devices.
>SIP and HTTP are examples, on existing phones and PCs at a minimum.
>Sure, new devices with new capabilities will come along;
>I'm working on some :), but whatever we do, it has to WORK
>on a "black" phone connected to a SIP gateway, or a current
>technology WAP phone, or the first gen 3GPP phones, and, believe
>it or not, the first level ethernet switch in the closet near
>you.

The best we can hope for with existing devices (excepting the PC, and
perhaps 1st generation 3G devices), is the protocol results in the
knowledge by the users of senders and receivers of these messages
there is NO privacy associated with the location messages exchanged.

That doesn't mean we can't set the ground so that succeeding
generations can negotiate the degree and limit of the information
revealed in the location messages.

>
>A critical need, my first application of this object, is to
>reveal location in an emergency call. Please tell me what
>SIP messages you want me to send and receive in order to
>send location. Yes, we can if needed, modify SIP, although
>it might be hard to totally redefine the protocol.

This is essentially what I propose we do.

>
>Please keep in mind the current bandwidth available to a 3GPP
>telephone for signalling (around 4Kbits), and the current processor
>available to run cryptographic operations.

It is for these reasons it is unrealistic to expect current
generation devices can assure any degree of location privacy.

> I don't care what the future will bring if the REQUIREMENTS must be met
>by current technology. What REQUIREMENTS are you placing
>on my current problem?

The requirement I seek is devices exchange the object. It is
reasonable to say the attributes defining access limits may be set to
indicate there is no limitation on the use of the information, but
doing so provides no assurance the information will not be used in
contexts beyond the current transaction.

If limitation on the use of the information is desired by the users,
senders and receivers must be capable of setting other values for
these attributes.

>
>Hmmm, I just listed several requirements. Let me restate them:
>1. The solution must be retrofitable into existing protocols such
>as HTTP and SIP.
>2. The solution must function on existing technology SIP gateways
>existing WAP-style mobile devices, first generation 3GPP handsets
>current generation PC technology, and existing first level manageable
>LAN switches. Software upgrades are acceptable.
>3. The solution must function on low bandwidth (e.g. kilobit-range)
>links with reasonable response times.
>5. The solution must support unattended devices

With the bounds I've set, I think these are all attainable. Bear in
mind the application of the protocol in these circumstances likely
won't improve the control over location information -- which is
essentially the situation we have today.

>4. The solution must support high-update-frequency tracking

This probably is unattainable because of bandwidth and capacity limitations.

best,

-- 
john noerenberg
jwn2@qualcomm.com
  --------------------------------------------------------------------
   Setting out on the voyage to Ithaca
   you must pray that the way be long,
   full of adventures and experiences.
   -- C.P. Cavavy, "Ithaca", 1911
   --------------------------------------------------------------------