RE: Terminology....Re: [Geopriv] SIP lbyr locationderefusingdraft-mahy-geopriv-sip-loc-pkg-02.txt

From: Marc Berryman ^lt;MBerryman@911.org>
Date: Mon Jul 16 2007 - 11:23:28 EDT

My comments should have been transmitted as "updated and presumably more
precise information" and not "updated and preassembly more information"

Marc B

-----Original Message-----
From: Marc Berryman [mailto:MBerryman@911.org]
Sent: Monday, July 16, 2007 10:21 AM
To: Rohan Mahy
Cc: rjs@estacado.net; GEOPRIV
Subject: RE: Terminology....Re: [Geopriv] SIP lbyr
locationderefusingdraft-mahy-geopriv-sip-loc-pkg-02.txt

Inserting an valid, more accurate, or "apparently" more accurate
location in to Geopriv is perfectly acceptable to me, what I am saying
is I have a great issue with "updated and preassembly more information"
vs. "fuzzied , filtered, or best guess" location information.

Marc B

-----Original Message-----
From: Rohan Mahy [mailto:rohan@ekabal.com]
Sent: Monday, July 16, 2007 9:58 AM
To: Marc Berryman
Cc: Rohan Mahy; Hannes Tschofenig; rjs@estacado.net; GEOPRIV
Subject: Re: Terminology....Re: [Geopriv] SIP lbyr location
derefusingdraft-mahy-geopriv-sip-loc-pkg-02.txt

Marc,

I certainly agreed to no such thing in this working group.

A very common use case in presence systems is that the presentity can
voluntarily disclose its (apparent) city and country. I can't
imagine any reason why a presence server should not be allowed to do
this processing after receiving a raw location in coordinate form.
Likewise, inside a presence document I can lie about my availability
and my location. I can provide a presence document that says I am
sleeping in California when I am actually out clubbing in Sweden.

You may be confusing the geopriv working space with the working space
for ecrit. Emergency applications clearly wants their location as
raw as they can get it and they want it to be truthful and accurate.

I hope you see why having one package for presence and one for
location can provide a clear distinction between these semantics.

thanks,
-rohan

On Jul 16, 2007, at 7:43 AM, Marc Berryman wrote:
> Rohan,
>
> I think we all agreed that the original way the location was
> determined
> would be the way the location is passed. There is no "Processed
> information" as you put it.
>
> To paraphrase a previous comment by Brian Rosen, "If the original way
> the location was determined yielded a civic, send the civic. If the
> original location was measured and yielded a geo, send the geo.
> Never,
> ever, convert."
>
> Marc B
>
> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@ekabal.com]
> Sent: Monday, July 16, 2007 9:28 AM
> To: Hannes Tschofenig
> Cc: Rohan Mahy; rjs@estacado.net; 'GEOPRIV'
> Subject: Re: Terminology....Re: [Geopriv] SIP lbyr location
> derefusingdraft-mahy-geopriv-sip-loc-pkg-02.txt
>
> Hannes,
>
> Thank you for bringing up this terminology question. What you
> described is not what I meant by raw vs. processed location. AFAIK
> the syntax of the document format is irrelevant. Below is my working
> definition.
>
> Raw location is a complete and accurate description of the location
> of a target without any fuzzing or obfuscation. Hopefully it will
> also contain a description of accuracy, and when and how the location
> was generated. In short, raw location is a "measurement".
>
> Processed location is a "presentation" of the *possible* location of
> a target. This location information should be filtered, it may be
> fuzzed (it might show my location as in the geographic center of
> Boston when I am in some suburb) or obfuscated, it may be entirely
> wrong (it may say that I am sitting at home when I am really in
> Bangkok). The accuracy may be omitted or reported as more or less
> accurate than reality.
>
> The semantics are very different. Traditional presence systems allow
> lying and filtering. They provide a "presentation" and IMO therefore
> provide an appropriate way to convey processed location. This
> processed location is used as supplemental information by the
> presence watcher. Raw location is needed by a variety of
> applications. Only one of these applications is presence and only
> one of them currently uses SIP. Exactly like calendar data or
> registration data, this raw location can be used as an *input* to
> presence systems.
>
> thanks,
> -rohan
>
>
> On Jul 16, 2007, at 1:38 AM, Hannes Tschofenig wrote:
>
>> There is a bit of terminology confusion.
>>
>> This is raw location information:
>>
>> <cl:civicAddress>
>> <cl:country>US</cl:country>
>> <cl:A1>New York</cl:A1>
>> <cl:A3>New York</cl:A3>
>> <cl:A6>Broadway</cl:A6>
>> <cl:HNO>123</cl:HNO>
>> <cl:LOC>Suite 75</cl:LOC>
>> <cl:PC>10027-0401</cl:PC>
>> </cl:civicAddress>
>>
>>
>> This is a PIDF-LO (from RFC 4119):
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <presence xmlns="urn:ietf:params:xml:ns:pidf"
>> xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
>> xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
>> entity="pres:geotarget@example.com">
>> <tuple id="sg89ae">
>> <status>
>> <gp:geopriv>
>> <gp:location-info>
>> <cl:civicAddress>
>> <cl:country>US</cl:country>
>> <cl:A1>New York</cl:A1>
>> <cl:A3>New York</cl:A3>
>> <cl:A6>Broadway</cl:A6>
>> <cl:HNO>123</cl:HNO>
>> <cl:LOC>Suite 75</cl:LOC>
>> <cl:PC>10027-0401</cl:PC>
>> </cl:civicAddress>
>> </gp:location-info>
>> <gp:usage-rules>
>> <gp:retransmission-allowed>yes</gp:retransmission-allowed>
>> <gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-
>> expiry>
>> </gp:usage-rules>
>> </gp:geopriv>
>> </status>
>> <timestamp>2003-06-22T20:57:29Z</timestamp>
>> </tuple>
>> </presence>
>>
>> When you fetch such a document from a LIS there is obviously no
>> Rich Presence in a similar fashion as there might not be rich
>> presence on an ordinary presence server either if it just does not
>> have the information.
>>
>> The information that is in a PIDF-LO beyond the raw location
>> information is useful and its good that this stuff is there. A long
>> time ago we decided that we would want to provide a PIDF-LO rather
>> than sending around raw location information.
>>
>> I don't see a need to define a new event package just because the
>> term LIS is not the same term as a presence server.
>>
>> Ciao
>> Hannes
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon, 16 Jul 2007 10:23:28 -0500

This archive was generated by hypermail 2.1.8 : Mon Jul 16 2007 - 11:23:42 EDT