Subject: [Geopriv] pdif-lo-08: rules

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Jul 2007 12:41:58 -0400

I believe the current rule set is confusing and unhelpful, if not  
outright wrong in places. It is confusing since it jumps around  
different levels and treats several different problems in an  
unstructured enumeration. It also uses both "same place" and  
"discrete location", making one wonder if they are the same thing.  
Neither the term 'priority' nor the term 'chunk' are defined. They  
just appear out of the blue in the rules.

Here's a suggestion for text that might be more readable, with each  
level in a different subsection. I've removed rule #3, since it  
violates the spirit of the long discussion that the SIMPLE working  
group had in arriving at RFC 4479. In particular, we discussed it as  
common that a user's device might be in a different place than the  
user, with the home PC and cellphone-left-on-dresser being oft-cited  
examples. Indeed, the whole composition discussion tried to deal with  
these aspects. I realize that not all authors of the draft  
participated in that discussion.

Rule #2 is also dubious. Putting different descriptions into separate  
tuples means replicating everything else about the service, including  
the contact. This is not a good idea and not generally necessary, as  
it breaks the semantics of tuples as service descriptors.

-- begin text ---

** Multiple PIDF documents

When multiple PIDF documents can be bundled in a single message,  
e.g., via MIME multipart, a recipient SHOULD consider the documents  
in order of appearance unless the location quality indicates otherwise.

** <geopriv> elements

Each <geopriv> element within a <tuple>, <device> or <person> element  
MUST describe a discrete location. Where a discrete location can be  
described in more than one way, such as in civic and geodetic  
coordinates or by different geometric shapes, each such description  
is placed in a separate <geopriv> element.

** <location-info> elements

<location-info> elements MAY contain compound locations describing a  
discrete location. In a compound location, the coarse location  
information MUST precede the finer grained information. For example,  
a single location element may contain a geodetic location for a  
house, in addition to a civic location element indicating the floor,  
with the geodetic location shown first.

--- end text ---

I'm not terribly happy with the location quality qualifier (which  
would need to be defined somewhere), but every SHOULD needs to have  
an 'unless', in my book, and that's the best I could come up with.

Henning

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 17 Jul 2007 14:00:33 -0500

Thanks for the comments Henning.
Quite a number of these are useful and welcome, even thought the WGLC is
over.. ;)

One comment in particular stood out as being at odds with the intent of
the document however.

"Here's a suggestion for text that might be more readable, with each
level in a different subsection. I've removed rule #3, since it violates
the spirit of the long discussion that the SIMPLE working group had in
arriving at RFC 4479. In particular, we discussed it as common that a
user's device might be in a different place than the user, with the home
PC and cellphone-left-on-dresser being oft-cited examples. Indeed, the
whole composition discussion tried to deal with these aspects. I realize
that not all authors of the draft participated in that discussion."

The intent of this document is now strongly emphasized in the overview:
"This document provides a specific set of guidelines for building
   presence documents when it is important to unambiguously convey
   exactly one location."

That is, if you want to use PIDF-LO in a general presence application
then the rules in this document need not apply. If you want to convey
where you, or your device is now, and you want to make sure that
everything understands that this is what you are doing, then follow
these rules and all should be okay.

Consequently I think that rule #3 is very important to the intent of
this document.

Cheers
James
------------------------------------------------------------------------------------------------
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: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Jul 2007 15:48:43 -0400

I don't think the WG ever agreed on that qualification of the intent  
of the document. There is no reason to go back and write another  
document for the more general presence case. Thus, I disagree with  
your conclusion.

On Jul 17, 2007, at 3:00 PM, Winterbottom, James wrote:

> violates

---

From: Robert Sparks <[email-masked]>
Date: Tue, 17 Jul 2007 14:56:44 -0500

Hrm. I was under the impression that the group had made this choice  
(before I was watching closely).

My understanding (which may need correcting) is that this document  
establishes a profile
that will only be used when the application using the pidf you're  
creating needs to be able
to with as little ambiguity as possible talk about one place. Is that  
not what this is? And is it
not the essence of the document? If it isn't, let me know what it is.

(Everyone please dogpile this - I need to know what everyone thought  
this is all about).

RjS

On Jul 17, 2007, at 2:48 PM, Henning Schulzrinne wrote:

> I don't think the WG ever agreed on that qualification of the  
> intent of the document. There is no reason to go back and write  
> another document for the more general presence case. Thus, I  
> disagree with your conclusion.
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 17 Jul 2007 15:20:22 -0500

I believe that your assessment is entirely correct Robert.

Cheers
James

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Wednesday, 18 July 2007 5:57 AM
> To: Henning Schulzrinne
> Cc: Winterbottom, James; GEOPRIV
> Subject: Re: [Geopriv] pdif-lo-08: rules
> 
---------------------------------------------------------------------
> >> ---------------------------
---------------------------------------------------------------------
> >> ---------------------------
> >> [mf2]
> >>
> >
> >
> >

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 17 Jul 2007 15:53:49 -0500

Yes - I understand the purpose as being to convey a single location.
There may be multiple representations of that one location (typical
example - geo plus civic plus jurisdictional civic)

Cheers,
Martin

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Wednesday, 18 July 2007 5:57 AM
To: Henning Schulzrinne
Cc: GEOPRIV
Subject: Re: [Geopriv] pdif-lo-08: rules

RjS

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Jul 2007 18:05:36 -0400

I thought the original motivation was that PIDF-LO, as described in  
RFC 4119, is under-specified in general, for any use, and that this  
needed fixing.

I have no problem having conditional text that says something like  
"For applications that require that only one location is delivered,  
the following additional considerations apply...". Location  
conveyance or whatever application that falls into that category  
(which I actually doubt in the particular case), could then simply  
refer to the "Section [Single-Location] of RFC4119bis applies here".

 From what I can tell, only "Rule #3" is affected by that, so it  
seems unnecessary to create a whole new document that says "Here's  
how can use PIDF-LO with our current SIMPLE architecture and data  
model".

That said, I've yet to see a convincing explanation for throwing away  
data that the end point has. Plus, in most cases, the restriction  
isn't actually verifiable. How can an intermediary tell that the  
street address and the geo coordinates really are the same place? (In  
another context, I mentioned the WiMax example. In that example, the  
end system had no way of knowing whether it actually was at 123 Main  
Street or not, i.e., it couldn't tell whether it was violating the  
one-point rule.)

We clearly need to tell routing logic along the way which location to  
use, if there's a difference. (In most cases, the answer would be  
"use any, since they are all the same building."). Dispatch and other  
human users want all the information that they can get, particularly  
if the information has different reliability-precision trade-offs;  
see my WiMax example again.

Also, note that we have so far only talked about the <tuple> case, as  
the document seems to be somewhat blissfully unaware of the SIMPLE  
work in the data model area. There is no ambiguity if multiple  
<device>s, for example, have different locations.

Henning

On Jul 17, 2007, at 3:56 PM, Robert Sparks wrote:

> to with as little ambiguity as possible talk about one place. Is  
> that not what this is? And is it
> (Everyone please dogpile this - I need to know what everyone  
> thought this is all about).

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 19 Jul 2007 13:28:46 -0700

Hi,

Clarifying the semantics of locations in various places in a PIDF-LO
seems pretty generally useful, so I am inclined to agree with Henning
on this one.

Take a look at the helpful figure from the draft:

   <?xml version="1.0" encoding="UTF-8"?>
   <presence>
      <tuple> -- #1
          <status>
               <geopriv> -- #1
                   <location-info>
                       location chunk #1
                       location chunk #2
                       ...
                       location chunk #n
                   <usage-rules>
               </geopriv>
               <geopriv> -- #2
               <geopriv> -- #3
               ...
               <geopriv> -- #m
          </status>
      </tuple>
      <tuple> -- #2
      <tuple> -- #3
      ...
      <tuple> -- #o
   </presence>

I would be pretty keen on the following semantics:
  - multiple chunks in the same <location-info> element in one
<geopriv> element are alternative representations of the same location
using the same source (ex: compound location)
 -  multiple <geopiv> elements inside the same tuple are alternative
measurements of the location of a single target
 - multiple <tuple> elements (typically) represent different devices
or targets and so they can have different locations altogether.  For
applications where only one location makes sense (emergency calls,
asset tracking), only send one tuple.

This would require changes to rule 1,2, and 3.  I'll provide some
alternate text here:

Rule #1: Any location information in a <tuple> element MUST describe
the same discrete location.

Rule #2: Where the same discrete location is determined using a series
of different techniques, the location determined by each technique
MUST reside in separate <geopriv> elements.

Rule #3: Providing more than one <tuple> element with location
information in a single PIDF document SHOULD only be done when the
application consuming the PIDF expects that more than one location may
be present.

Hopefully this makes sense.

thanks,
-rohan

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Jul 2007 16:43:27 -0400

I like this a lot. 

To this, we need to work in the text in location conveyance that talks about
multiple location objects in one Geolocation header.  There is a case which
won't quite meet your "pattern" here which is where you provide both an LbyR
and an LbyV for the same point on earth.

Brian

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Thursday, July 19, 2007 4:29 PM
> To: Henning Schulzrinne
> Cc: GEOPRIV

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 19 Jul 2007 17:00:06 -0500

Thanks Rohan. I think that this keeps the general spirit of what we are
trying to say. Precedence for selection for routing etc will still be
based on position in the document however. Does that seem reasonable
given that timestamps are optional?

Cheers
James

> Sent: Friday, 20 July 2007 6:29 AM
> To: Henning Schulzrinne
> Cc: GEOPRIV

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 19 Jul 2007 17:26:47 -0700

Hi,

I don't have a problem picking a default metric for precedence (such
as document order) even if the decision is arbitrary, as long as the
default is a SHOULD instead of a MUST.  The current Rule #8 has a
SHOULD, so I'm fine with it.   If the tuples had optional confidence
values for example, that would be a good reason to ignore the default
and use the tuple with the best confidence.

thanks,
-rohan

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Jul 2007 21:49:04 -0400

>   </presence>

I would suggest adding the <person> and <device> elements from the  
data model to this figure, as it helps clarify the rules.

> measurements of the location of a single target

Agreed.

> asset tracking), only send one tuple.

In the data model, <tuple>s represent services, i.e., different URLs.  
I'm unsure whether restricting this to one tuple always makes sense,  
but maybe these application-specific cases are best left to the phone- 
bcp in any event. I'd rather not spread emergency-only behavior  
across different documents. (A forward reference from the pdif-lo  
document to the phone-bcp is obviously a good idea.)

My concern is that if somebody gets their own location by subscribing  
to their own PIDF, they shouldn't have to filter out the extra  
tuples. The (dumb) end system may have no clue as to which one is  
appropriate and the source of the PIDF may have no idea that this  
particular consumer can only grok one.

> application consuming the PIDF expects that more than one location may

My concern with this is that it is unclear how the sender can  
ascertain that expectation. I'd simply say that specific application  
domain may restrict the number of <tuple>s to one.

As I've remarked in another context, I find the current enumeration  
hard to follow. I'd rather have rules for each element or sub-element  
that are labeled as section. I had provided text along those lines  
earlier.

Henning