Re: [Sip] SIPit 20 survey summary

"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> Sun, 29 April 2007 15:11 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiB3g-0006zc-NU; Sun, 29 Apr 2007 11:11:28 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HiB3f-0006zT-CC for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 11:11:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiB3f-0006zL-2d for sip@ietf.org; Sun, 29 Apr 2007 11:11:27 -0400
Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiB3e-0002pV-H7 for sip@ietf.org; Sun, 29 Apr 2007 11:11:27 -0400
Received: (qmail 19688 invoked by uid 0); 29 Apr 2007 15:11:25 -0000
Received: from 90.187.53.37 by www082.gmx.net with HTTP; Sun, 29 Apr 2007 17:11:25 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 29 Apr 2007 17:11:25 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
In-Reply-To: <4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu>
Message-ID: <20070429151125.77890@gmx.net>
MIME-Version: 1.0
References: <20070429143911.77880@gmx.net> <4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu>
Subject: Re: [Sip] SIPit 20 survey summary
To: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX19QVVAD4NtQLVk2BgLRhyLtI8NI3wB3zp7t8Y/il6 KA0w1U+EELfFFSRLBk5dpefuHcP5/JpKAjBQ==
Content-Transfer-Encoding: 7bit
X-GMX-UID: /NxBdVkrODB6Q5kCsWVMsFQ9Ji9SWlJW
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: sip@ietf.org, discussion@sipforum.org, jh@tutpro.com, sip-implementors@cs.columbia.edu, rjsparks@estacado.net
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hi Henning, 

even for the geodetic location information we never came to a clear conclusion how many shapes we need as mandatory to understand by specific nodes. The PIDF-LO profiles draft is listing a number of shape types and currently they are all marked as "mandatory-to-implement". 
 
Given that some location determination techniques produce certain shape types we can only discuss whether it makes sense to reduce the quality of the data already at the Location Generator before further distributing it. 

That's, btw, something we still have to decide for the emergency services use case (and it will need to be described in Phone BCP). I have sent a few mails to PSAP operators to learn what type of location shapes they process today. 

I don't care whether the information is carried in the header or in the body. If it is supposed to be consumed by the end points only then I would argue that is is just fine to convey it within the body. Hence, we are largely discussing location-based routing applications here. 

Ciao
Hannes

-------- Original-Nachricht --------
Datum: Sun, 29 Apr 2007 10:56:24 -0400
Von: Henning Schulzrinne <hgs@cs.columbia.edu>
An: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
CC: jh@tutpro.com, rjsparks@estacado.net, discussion@sipforum.org, sip-implementors@cs.columbia.edu, sip@ietf.org
Betreff: Re: [Sip] SIPit 20 survey summary

> I mis-spoke. I was actually thinking of a different solution, more  
> appropriate to the SIP header model. After all, for geo, two numbers  
> (long/lat) in WGS84 datum are all that matters in most circumstances,  
> on occasion augmented by a third (some 'measurement accuracy'  
> indication).
> 
> The XMPP XML model that Juha and you refer to isn't all that much  
> simpler than GEOPRIV civic or GML Point, just different, as you note.  
> (Whether supporting the multitude of geometric shapes in the pdif-lo  
> profile spec is truly required and where is another discussion which  
> belongs elsewhere.)
> 
> I don't know if by 'security' you refer to the embedded privacy  
> policies; in most cases, restrictive default values would do the  
> trick for those. Plus, for emergency calls, few PSAPs are going to  
> observe 'do not distribute' or 'do not retain' in any event, simply  
> because the law in many jurisdictions contradicts those desires.
> 
> Henning
> 
> On Apr 29, 2007, at 10:39 AM, Hannes Tschofenig wrote:
> 
> > Hi Henning,
> >
> > http://www.xmpp.org/extensions/xep-0080.html takes an interesting  
> > approach by largely ignoring previous work on geolocation. It is  
> > just too attractive to create your own flavor of civic and geodetic  
> > location information format.
> >
> > Interestingly enough there is a full-blown solution for XMPP  
> > available as well that builds on the OMA protocols. I have to  
> > search for the reference, if someone cares. That one is far more  
> > complex than GEOPRIV.
> >
> > If you argue for simplicity then you refer to  http://www.xmpp.org/ 
> > extensions/xep-0080.html.
> >
> > If you argue for functionality, different environments and  
> > interworking with existing systems then you point to the OMA  
> > extension.
> >
> > It's so easy. Translated to our work in GEOPRIV this would mean the  
> > following: If we want to convince people to use it then we just  
> > point them to the easy WLAN or enterprise case with a simple civic  
> > or a simple point representation.
> >
> > Ciao
> > Hannes
> >
> > PS: Last November I was at a conference on mobility protocols.  
> > Someone gave a presentation on a new mobility protocol design. The  
> > author claimed it was very simple. Indeed, it was simple -- because  
> > it just didn't care about security.
> >


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip