Subject: [Geopriv] New Version Notification for draft-busin-geopriv-location-qos-req-00

From: Salvatore Loreto <[email-masked]>
Date: Tue, 13 Nov 2007 14:57:19 +0200

we just submitted a requirement draft for a Location Quality of Service
(QoS) Information Object:

http://tools.ietf.org/wg/geopriv/draft-busin-geopriv-location-qos-req-00.txt

Comments and feedback appreciated.

Salvatore Loreto

On Mon, 2007-11-12 at 04:03 -0500, IETF I-D Submission Tool wrote:
> A new version of I-D, draft-busin-geopriv-location-qos-req-00.txt has been successfuly submitted by Salvatore Loreto and posted to the IETF repository.
> 
> Filename:	 draft-busin-geopriv-location-qos-req
> Revision:	 00
> Title:		 Requirements for a Location Quality of Service (QoS) Information Object
> Creation_date:	 2007-11-11
> WG ID:		 Independent Submission
> Number_of_pages: 9
> 
> Abstract:
> This document describes requirements for Location Quality of Service
> (QoS) Information Object.  The Location QoS Information Object is
> used for expressing the geographic location QoS information in terms
> of specifying the required or desired level of quality, accuracy,
> response time, and age of requested Location Information.  The
> resulting Location Information is conveyed in existing location
> formats wrapped in GEOPRIV privacy extensions to the Presence
> Information Document Format (PIDF-LO) [RFC4119].
>                                                                                   
> 
> 
> The IETF Secretariat.
> 
> 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 Nov 2007 13:27:53 -0600

Hi Guys,

Just a cursory read, but these values are being positioned as location
request parameters to be included in a resulting PIDF-LO. Some of these
parameters are already provided in HELD as part of the location request,
others, such as horizontal accuracy for example and explicit in any
geodetic response.

Perhaps you can explain a little better why I would want to request a
specific horizontal accuracy within a specific time inside a PIDF-LO?

Cheers
James

> -----Original Message-----
> From: Salvatore Loreto [mailto:[email-masked]]
> Sent: Tuesday, 13 November 2007 11:57 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: [Geopriv] New Version Notification for draft-busin-geopriv-
> location-qos-req-00
> 
> > A new version of I-D, draft-busin-geopriv-location-qos-req-00.txt
has
> been successfuly submitted by Salvatore Loreto and posted to the IETF
> repository.
> >
> > Title:		 Requirements for a Location Quality of Service
(QoS)
> Information Object

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Nov 2007 23:07:01 +0100

Hi Salvatore,

thanks for posting the document.

Along the lines of James's comments I believe that it would be important 
to separate
* the request
from
* the actual payload of the PIDF-LO in the response.

Regarding the latter item, I am fine with adding new elements in PIDF-LO 
(although the proposed elements need to be discussed). We have other 
documents

On the former part, the PIDF-LO is a container for location and privacy 
policy. It is not a protocol. Hence, requests are specific to the usage 
environment you have in mind. For example, you might want to consider 
HELD when you request location information using an HTTP based protocol 
from a LIS.

This is not a show stopper; this confusion might have just been caused 
by the potentially not so well documented worksplit between the 
protocols involved in the GEOPRIV architecture.

Ciao
Hannes

---

From: "Moore, Lyn E" <[email-masked]>
Date: Wed, 14 Nov 2007 09:13:33 +1100

Hello All

I agree with James' comment on the accuracy and timing.  Please
explain...

Everyone will want the most accurate and the quickest response when
given the right to specify; regardless of whether it is necessary or
not.  Has anyone given any thought to how this would be achieved ?  For
most carriers providing LBS, this could involve multiple positioning
technologies on multiple access networks with hundreds of different
applications all requesting different levels of QoS.  This is basically
unmanageable, and I would doubt any carrier would implement it unless it
became a regulatory requirement.

Carriers providing LBS already have this information.  Yes, it could be
incorporated into the response for emergency calling and/or if the user
has access to multiple positioning technologies and wishes to choose
one.  However, I believe it is the LBS provider who is in the best
position to decide what degree of accuracy and timeliness is required
for an LBS application.  Again, this will be dependent on what
positioning technologies are available to the user.  

Regards
Lyn

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Wednesday, 14 November 2007 6:28 AM
To: Salvatore Loreto; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Geopriv] New Version Notification
fordraft-busin-geopriv-location-qos-req-00

Hi Guys,

Cheers
James

has
(QoS)

> > Information Document Format (PIDF-LO) [RFC4119].

------------------------------------------------------------------------
------------------------
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender immediately
and delete the original.  Any unauthorized use of this email is
prohibited.
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Tue, 13 Nov 2007 16:06:42 -0700

This email dialogue triggered a thought on a related by different topic. The 
OGC members have been working on developing and (sson) approving a new OGC 
standard that extends GeoXACML so that geographic constraints for 
authorization can be specified. This work has been coordinated with the 
OASIS XACML TC.

Anyway, there are similar issues regarding accuracy and quality of service. 
So, the group is crafting is disclaimer to be prominently displayed in the 
front of the document.

   "Issues of absolute or relative accuracy of feature geometry and 
positioning data and the computational stability of finite precision 
arithmetic as used in all computers will affect results where distance 
measure, geometry or positional values are compared. For this reason, and 
the variety of statistically valid but different implementation approaches 
to these issues, Boolean criteria as used in XACML or GeoXACML policy 
statements will not always produce uniform results across geographic 
implementations. For these reasons, users of this technology should not ask 
for fine gradations of measures that their data or coordinate transformation 
cannot support, but should alternately allow a "tolerant" approach where 
feasible which might give access to slightly more data than would be given 
in a perfect computational, but impossible to implement, environment."

This is still a work in progress but I wonder if we need a similar statement 
in some of the documents developed or in development by this group?

Just wondering.

Regards

Carl

----- Original Message ----- 
From: "Moore, Lyn E" <[email-masked]>
To: "Winterbottom, James" <[email-masked]>; "Salvatore 
Loreto" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, November 13, 2007 3:13 PM
Subject: RE: [Geopriv] New Version 
Notificationfordraft-busin-geopriv-location-qos-req-00

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 13 Nov 2007 17:26:53 -0600

Actually Carl, this comment is more applicable to discussion on a related draft.  It's an excellent comment though; it highlights a central concern that has been troubling the group, particularly in light of comments on geopriv-policy.

This probably an opportune moment to hijack the thread to announce my draft...

   <http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty>

RFC 3693 says:

   Resolution and Precision are very close terms.  Either quality can be
   'reduced' to coarsen location information: 'resolution' by defining a
   off-center perimeter around a user's location or otherwise enlarging
   the area in consideration (from state to country, say) and
   'precision' by discarding significant digits of positioning
   information (rounding off longitude and latitude from seconds to
   minutes, say).  Another WG document discusses this topic in much more
   detail.

This is that document.  I have certainly added the "much" to the more detail.  This draft attempts to address the goals that I outlined in an earlier email:

"
The first is to resolve the definitions of Uncertainty and Confidence and to deprecate the usage of Precision and Accuracy. Precision and Accuracy have myriad meanings and while the 3693 definitions are good, they aren't concrete enough terms for our purposes.

(Originally, I had hoped that the definitions in GeoShape would suffice, but it's clear that those haven't done the job, or at least people haven't read it.)

The second goal is to define some guidelines on how to apply uncertainty in determining if a Target is within a given region. This applies directly to the geopriv-policy and loc-filters work.

The third goal, potentially the most controversial one, is to formalize the addition of Confidence to the PIDF-LO representation and to define a default value that can be assumed when none is present.
"

I don't expect this to sink in over the next few weeks before the next meeting, but I'd appreciate it if people took the time to read it before discussing anything related to uncertainty and confidence (or accuracy, precision and resolution for that matter).

Regards,
Martin

> From: Carl Reed OGC Account [mailto:[email-masked]]
> Sent: Wednesday, 14 November 2007 10:07 AM
> To: Moore, Lyn E; Winterbottom, James; Salvatore Loreto; [email-masked]
> Subject: Re: [Geopriv] New VersionNotificationfordraft-busin-geopriv-
> location-qos-req-00
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 13 Nov 2007 17:32:19 -0600

Hi Lyn,

I think that this is going a little too far into the land of assumptions.  I have to disagree with your point on QoS.  We have to expect a wide range of users of location information.  Currently, the primary users are actually specialist location services developers who most certainly know what they want and are cognizant of limitations.

Existing LBS systems already have the QoS capabilities described in the draft.  I'm well familiar with the implementation of these sorts of functions; they are less onerous than it seems on first impressions.

Also note that these requirements almost directly describe the eqop element of MLP [1].  Functional parity with that specification is not a bad idea.  I had similar goals for HELD [2], but other drafts were needed first [3].

So, for the authors of this document, can we please have some better explanation of what your intentions are?  I'm afraid that the draft isn't clear enough on this point.

In particular, please clarify whether or not you see a Location Quality of Service Information Object as a part of a Location Object (as an indication of quality) or as a request object in some protocol.  Personally, I see these as protocol parameters, but I can't make a judgment on the object since it isn't clear exactly how it would be used.

Cheers,
Martin

[1] <http://www.openmobilealliance.org/release_program/mls_v1_1.html>

[2] From a design perspective, these parameters were considered for inclusion in HELD, but we decided to limit the set of parameters to one: response time.  That turned out to be controversial enough!
    The HELD design is consistent with the approach used in more recent LBS specifications.  That is, the response time is the only binding parameter (hence the desire to get it in the base specification).  Extra parameters like horizontal accuracy are more like guidelines; the server should attempt to meet them, but it shouldn't fail to produce a result if it doesn't.  Instead, it indicates whether or not the target QoS parameter was met and the client is able to decide if it will accept the result.  This would invalidate the QoS class of service parameter.

[3] <http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty>

> From: Moore, Lyn E [mailto:[email-masked]]
> Sent: Wednesday, 14 November 2007 9:14 AM
> To: Winterbottom, James; Salvatore Loreto; [email-masked]
> Subject: RE: [Geopriv] New Version Notificationfordraft-busin-geopriv-
> location-qos-req-00
> 
> Hello All
>

---

From: "Moore, Lyn E" <[email-masked]>
Date: Wed, 14 Nov 2007 12:43:23 +1100

Thanks Martin
Yes I understand your point.... but there are still have practical
issues here in relation to the positioning technology used/available
versus the degree of accuracy required.  There is no guarantee that a
user won't use a service even if it does require a higher degree of
accuracy, just because they can.  This adds to the burden of the carrier
providing the LBS as the poor customer experience will reflect poorly on
them.

Cheers
Lyn 

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Wednesday, 14 November 2007 10:32 AM
To: Moore, Lyn E; Winterbottom, James; Salvatore Loreto;
[email-masked]

Hi Lyn,

I think that this is going a little too far into the land of
assumptions.  I have to disagree with your point on QoS.  We have to
expect a wide range of users of location information.  Currently, the
primary users are actually specialist location services developers who
most certainly know what they want and are cognizant of limitations.

Existing LBS systems already have the QoS capabilities described in the
draft.  I'm well familiar with the implementation of these sorts of
functions; they are less onerous than it seems on first impressions.

Also note that these requirements almost directly describe the eqop
element of MLP [1].  Functional parity with that specification is not a
bad idea.  I had similar goals for HELD [2], but other drafts were
needed first [3].

So, for the authors of this document, can we please have some better
explanation of what your intentions are?  I'm afraid that the draft
isn't clear enough on this point.

In particular, please clarify whether or not you see a Location Quality
of Service Information Object as a part of a Location Object (as an
indication of quality) or as a request object in some protocol.
Personally, I see these as protocol parameters, but I can't make a
judgment on the object since it isn't clear exactly how it would be
used.

Cheers,
Martin

[2] From a design perspective, these parameters were considered for
inclusion in HELD, but we decided to limit the set of parameters to one:
response time.  That turned out to be controversial enough!
    The HELD design is consistent with the approach used in more recent
LBS specifications.  That is, the response time is the only binding
parameter (hence the desire to get it in the base specification).  Extra
parameters like horizontal accuracy are more like guidelines; the server
should attempt to meet them, but it shouldn't fail to produce a result
if it doesn't.  Instead, it indicates whether or not the target QoS
parameter was met and the client is able to decide if it will accept the
result.  This would invalidate the QoS class of service parameter.

> not.  Has anyone given any thought to how this would be achieved ?  
> For most carriers providing LBS, this could involve multiple 
> positioning technologies on multiple access networks with hundreds of 
> different applications all requesting different levels of QoS.  This 
> is basically unmanageable, and I would doubt any carrier would 
> implement it unless it became a regulatory requirement.
> 
> Carriers providing LBS already have this information.  Yes, it could 
> be incorporated into the response for emergency calling and/or if the 
> user has access to multiple positioning technologies and wishes to 
> choose one.  However, I believe it is the LBS provider who is in the 
> best position to decide what degree of accuracy and timeliness is 
> required for an LBS application.  Again, this will be dependent on 
> what positioning technologies are available to the user.
> 
> Regards
> Lyn
> 
> 

> request parameters to be included in a resulting PIDF-LO. Some of 
> these parameters are already provided in HELD as part of the location 
> request, others, such as horizontal accuracy for example and explicit 
> in any geodetic response.
> 

> > http://tools.ietf.org/wg/geopriv/draft-busin-geopriv-location-qos-re
> > q-
> > 00.txt
> >
> > been successfuly submitted by Salvatore Loreto and posted to the 
> > IETF repository.
> > >

---

From: Åke Busin <[email-masked]>
Date: Wed, 14 Nov 2007 07:40:15 +0100

James, 

Belive we have a slight missunderstanding here. This QoS object is not intended to be carried in a PIDF-LO but in the message (e.g. SIP SUBSCRIBE)requesting location information.

PIDF-LO is mentioned in the abstract, but just as the format carrying the resulting locaiton information.

"The resulting Location Information is conveyed in existing location formats wrapped in GEOPRIV privacy extensions to the Presence Information Document Format (PIDF-LO) [RFC4119]."

BR

Åke

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: den 13 november 2007 20:28
To: Salvatore Loreto; [email-masked]
Cc: Miran Mosmondor; Åke Busin; Yufeng Jin
Subject: RE: [Geopriv] New Version Notification for draft-busin-geopriv-location-qos-req-00

Hi Guys,

Just a cursory read, but these values are being positioned as location request parameters to be included in a resulting PIDF-LO. Some of these parameters are already provided in HELD as part of the location request, others, such as horizontal accuracy for example and explicit in any geodetic response.

Perhaps you can explain a little better why I would want to request a specific horizontal accuracy within a specific time inside a PIDF-LO?

Cheers
James

has
(QoS)

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender immediately and delete the original.  Any unauthorized use of this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Åke Busin <[email-masked]>
Date: Wed, 14 Nov 2007 08:26:29 +0100

Martin, Lynn & all,

As also stated I earlier reply this draft intends to define requirements for an object the should be carried in a request for location information, sorry for not being clear on this. It is true the requirement describe a subset of the QoS element in MLP. These where chosen as they represent a stable and widely deployed set of QoS parameters in LBS.

Regarding the need and the permission to specify a requested QoS we need to bear in mind that there are and will be a wide range of users of location information. The discussion seems a bit stuck on a irresponsible user that request location 'for  fun' and at no cost for the user. This draft is focused on the need of fairly complex applications that utilize location and where the need on e.g. Accuracy and latency are quite dymanic. The assumption is also that the Location Server do apply different positioning technologies depending on the requested QoS.

BR
Åke

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: den 14 november 2007 00:32
To: Moore, Lyn E; Winterbottom, James; Salvatore Loreto; [email-masked]
Cc: Miran Mosmondor; Åke Busin; Yufeng Jin
Subject: RE: [Geopriv] New Version Notificationfordraft-busin-geopriv-location-qos-req-00

Hi Lyn,

Cheers,
Martin

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 16 Nov 2007 15:51:50 +0200

Hi James,

well, we have to apologize to not have been quite clear in the draft
about the fact that the intention of requirement draft is to find a way
to identify specific QoS parameters to insert in a location request.
We'll try to clarify better everything in the next version of the draft,
that we'll be send out soon.

I am very well aware that in HELD is already possible specify those
parameters, and I think that it is important having those possibility in
HELD.
However in a SUBSCRIBE it is not possible, or at least not yet.

I have been told one month ago in this same mailing list that the wg is
not going to draft a specific Event Package for location, because the wg
thinking that the one for presence works pretty well also for location.
However so far there is no way to specify in the SUBSCRIBE request,
using both presence event package and also location filters, the QoS
that I'd like to receive in the answer. 

Having said that I think the aim of the document becomes more clear.

regards
Sal

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 16 Nov 2007 08:57:42 -0500

I have some interest in this idea.  It would also be useful in other
contexts besides SUBSCRIBE.  There is nothing specific to HELD about these
issues; they apply to all LCPs and location dereference protocols.

Brian

> Sent: Friday, November 16, 2007 8:52 AM
> To: Winterbottom, James
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Geopriv] New Version Notification fordraft-busin-geopriv-
> location-qos-req-00
> 
> Hi James,
>

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 16 Nov 2007 16:30:52 +0200

I agree it applies to all LCPs and location deference protocols,
and we should discuss in general, we'd be glad to work on solve this
issue together.

however I do believe we should also discuss the different protocols;
and as HELD already contemplate the possibility, it should be great to
have the possibility to request QoS also using SUBSCRIBE.

Sal

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Thu, 29 Nov 2007 12:57:32 -0700

Salvatore -

I have finished reviewing the 
http://tools.ietf.org/wg/geopriv/draft-busin-geopriv-location-qos-req-01.txt 
document.

A few suggestions/comments.

1. Section 1.1. In the benefits list, there is one benefit that always seems 
to be left out when discussing Quality - whether quality of data or quality 
of service. This benefit has to do with legal considerations. While legal 
considerations may not be part of the purview of this WG, I know that in 
both OMA and the OGC, quality is a major issue in terms of legal exposure. 
For example, suppose that a consumer uses a location service but due to poor 
location data - and no notification to the consumer in terms of the quality 
of the location - some level of "injury" results. Injury could be any 
variety of things from emotional trauma to missing a key meeting to personal 
physical injury. One of the reasons the OGC is getting more heavily into 
Quality issues is that we want to be able to warn consumers whether the map 
data/location data they are using is "fit for purpose". By being able to 
provide such information, legal exposure could be significantly reduced for 
the location service provider.

2. Section 4.1. It might be useful to provide a generic definition of 
horizontal accuracy before defining horizontal accuracy within the context 
of the work of the GeoPRIV WG

3. Section 4.2: Ditto for vertical accuracy.

Or perhaps just a general definition for location accuracy, such as "The 
closeness of results of observations, computations, or estimates of graphic 
map features to their true value or position". (From GIS Glossary, Data West 
Research). I can get one that is not part of a  copyrighted book.

I will also await comments from the OGC Quality WG.

Regards

Carl

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 30 Nov 2007 16:06:02 +0200

Hi Carl,

thanks for reviewing and comments the draft.

You are completely right, we should also consider the benefit related
with legal consideration.
We'll insert this in the next version of the draft.

About the location accuracy, 
our intention is to use "accuracy" to describe the required level from
the application perspective, so that proper position determination
technology can be chosen by the location server. 

I also think that is good have a general definition of accuracy.

thanks
Sal