RE: crypto delay (Notes from Non-meeting)

At 05:01 PM 4/3/2002 -0500, you wrote:
> > Now on to other things..
> >
> > What is the location object be are all talking about ? XML?
> > ASN.1 <just
> > kidding>

>Oh, I think XML is pretty good. Generally, I think we plan to copy
>something that works, although we have some issues others may not have
>to deal with.

I would agree but then it brings up the subject of XML parsers in low power
/ low horsepower devices like cellphones

I thought the core consensus in the non BOF BOF is that of what we are
dealing with is a object and not a protocol. Protocols may use the location
object but we are not defining how they should use it. How SIP might use a
location object is a SIP issue ..not a geopriv one..however after the
ENUM/SIP discussions it becomes clear the lines of discussions start to
blur very quickly :-)

geopriv presumably is a discussion of two distinct issues physical location
and privacy..so it stands to reason that the object under discussion may
have two distinct features ..A. a semantical representation of physical
location and a separate but distinct privacy object that describes the
privacy policy to be used in association with the location object.

Either the privacy policy is imbedded in the location object ..or the
object contains a pointer to some other privacy object.

This looks more and more like a vCard vCalendar like problem statement all
the time ..which simplifies the requirements and work plan.

> >
> > What is the semantical expression of location object the PSAP needs?
> > Typically it keys a database look up based on TN to address.
> > PSAP address
> > databases are simply subsets of LIDB or DA information
> > supplied by the
> > LEC's this is now complicated by the mobile environment where formal
> > Lattitude and Longitude are used ..again keyed to address.
>My thinking is that the object has both lat/lon/altitude as well as
>planet/country/state/county/city/street/building/floor/room/cube, with
>translation flags. In the emergency call scenario, you start with one,
>translate to find the other if you can, look up the lat/lon in the
>database to find which PSAP, and send both to the PSAP.
>
>(security note - translators muck with the data; have to be in the
>trust loop).

and or first preform the PSAP look up hand off to a proxy and then you give
the PSAP what you have ..in the interest of speed and assume it has the
DB's necessary to translate but some of these requirements are
jurisdictional its just that the object need to be able to express a
variety of options.

> >
> > So in those environments where E.164 addressing is uesd that is a
> > requirement...not we have the problem of sip URI's
>Yeah, for now you actually send the E.164. We may need to create a database
>of E164s to PSAP (I hope not - depends on the gateway network architecture)

those exist its generally maps LATA boundries to NXX prefixes..I'm not sure
how the Europeans do it.

>Note to you privacy folks that in this case E.164 = location - there is
>an existing database that translates E.164 to street
>address/building/floor/...
>
> >
> > Now what other paramaters does it need to transmit?
> >
> > TTL?
>Oh, cute, I like it!
>
> >
> > Confidence Factor ? By this I mean ..whatever system generates the
> > location information may be able to transmit its Confidence in the
> > reliability of the data. This might be useful in those cases
> > where L/L
> > triangulation is difficult or is unable to reach pinpoint accuracy.
>Yeah, the whole object actually needs an accuracy estimate in it as
>well as a confidence. The spec needs a way to intentionally degrade
>accuracy, but that's another story.

but this the right track we need to consider in requirements

> >
> > I'm just thinking out loud about what could or should not be
> > included in
> > the object.
>Well, we have discussed previously that you may need a time stamp.
>Some folks want motion vectors

oh cool .. yes motion relates to accuracy or perhaps last two known points
of location in order to reference direction ... oh this gets fun ..its not
just LL but direction SSE NNW ..

>There are things associated with the datum used when you have lat/lon
>The translation thing is really more than a flag; you probably want
>some kind of identifier (signature in some cases) of who did the translation

excellent point

>I'd love to actually start working on that stuff - it's real engineering,
>and we can actually get it done in a finite period of time.

I agree ... there is no "protocol" here ..just data objects one is location
and maybe motion the other is a privacy policy object that is either linked
to or imbedded in the object. I need to re read some of the W3C work on P3P
to see is there is something that can be snarfed up and reused.

http://www.w3.org/P3P/

>Brian

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza Bldg 8 Sterling, VA 20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237
<mailto: rshockey@ix.netcom.com> or
<mailto: rich.shockey@neustar.biz>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Received on Sat Apr 6 19:39:21 2002