Re: Requirements Document

Greetings:

It would be demanding, from a requirements perspective, to define
this "object" to reveal location information for WAP, 3G & SIP phones as a
generic framework.

Network topology, signalling, methods used for revealing location
information can vary
in all three. Infact, WAP has a location charter of its own, 3G has come up
with some
initial drafts about location. Converging the standards and expecting them
to inter-operate
with a new technology like "location" would be an oversight.

So a recommendation would be that SIP make all the necessary
changes,updates (from a signalling perspective) to add/reveal the location
information.

Regards,

Bobby Sardana.
sardana@obsoft.com

"Rosen, Brian" 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.
>
> I don't really understand how you intend to accomplish our
> goals. We are defining the requirements for an object. We
> aren't defining a protocol, 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.
>
> 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.
>
> 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. 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?
>
> 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.
> 4. The solution must support high-update-frequency tracking
> 5. The solution must support unattended devices
>
> Brian
>
> > -----Original Message-----
> > From: John W Noerenberg II [mailto:jwn2@qualcomm.com]
> > Sent: Thursday, August 23, 2001 6:26 PM
> > To: Rosen, Brian
> > Cc: 'Randy Bush'; geopriv@mail.apps.ietf.org
> > Subject: RE: Requirements Document
> >
> >
> > At 9:20 AM -0400 8/23/01, Brian Rosen wrote:
> > > > >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.
> >
> > Our goal is to insure that location information is revealed in
> > compliance with the agreement between the sender's controller and the
> > receiver's controller. We must assume that each transaction is
> > independent. Therefore the access rights applying to any particular
> > transaction must be included in every transaction. To do otherwise
> > allows the condition that location revelation is not controlled by
> > security considerations in every circumstance. This would be a
> > fundamental flaw.
> >
> > >
> > >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.
> >
> > I say with all respect, the UI capability of the end device is not
> > our primary concern. First, we must create a protocol which insures
> > privacy considerations of sender and receiver are respected to the
> > greatest degree possible.
> >
> > >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.
> >
> > This is only reasonable in terms of devices which were designed
> > several years ago. Do not be bound by this. We must not be bound by
> > this. We are designing for devices to be built tomorrow, not
> > yesterday.
> >
> > >
> > >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.
> >
> > If they are optional, they are meaningless.
> > --
> >
> > john noerenberg
> > jwn2@qualcomm.com
> >
> > ----------------------------------------------------------------------
> > Like the Sorcerer's Apprentice, we succeeded beyond our
> > wildest dreams and our worst fears.
> > -- Steve Crocker, quoted in Wired Magazine, Apr, 1999
> >
> > ----------------------------------------------------------------------
> >
Received on Sun Aug 26 06:25:57 2001