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

From: Rohan Mahy ^lt;rohan.mahy@gmail.com>
Date: Thu Jul 19 2007 - 20:26:47 EDT

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

On 7/19/07, Winterbottom, James <James.Winterbottom@andrew.com> wrote:
> 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
>
>
> > -----Original Message-----
> > From: Rohan Mahy [mailto:rohan.mahy@gmail.com]
> > Sent: Friday, 20 July 2007 6:29 AM
> > To: Henning Schulzrinne
> > Cc: GEOPRIV
> > Subject: Re: [Geopriv] pdif-lo-08: rules
> >
> > 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
> >
> > On 7/17/07, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
> > > 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:
> > >
> > > > 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).
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
>
> ------------------------------------------------------------------------------------------------
> 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]
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 19 Jul 2007 17:26:47 -0700

This archive was generated by hypermail 2.1.8 : Thu Jul 19 2007 - 20:26:58 EDT