RE: [Geopriv] Comments on HELD-03

Yes, that is better


> -----Original Message-----
> From: Thomson, Martin
> Sent: Tuesday, 8 January 2008 9:04 AM
> To: Winterbottom, James; Stuard, Doug; 'Ted Hardie'; 'Mary Barnes';
> 'Arolick, Eric'; 'geopriv@ietf.org'
> Subject: RE: [Geopriv] Comments on HELD-03
> 
> I like it.  However, it does say "reference to the most current
available
> _reference_".  This should probably be "reference to the most current
> available _location information_".
> 
> > -----Original Message-----
> > From: Winterbottom, James
> > Sent: Tuesday, 8 January 2008 8:29 AM
> > To: Stuard, Doug; 'Ted Hardie'; 'Mary Barnes'; 'Arolick, Eric';
Thomson,
> > Martin; 'geopriv@ietf.org'
> > Subject: RE: [Geopriv] Comments on HELD-03
> >
> > Doug,
> >
> > Ted's response hit the spirit of what I was trying to get at and I
am
> more
> > than happy with his wording.
> >
> > Different URIs will result in different types of behaviour at the
LIS
> and
> > its subsequent responses. Defining, creating and controlling these
URIs
> is
> > what the Context Management document
(http://tools.ietf.org/html/draft-
> > winterbottom-geopriv-held-context-01) addresses.
> >
> > Cheers
> > James
> >
> >
> > > -----Original Message-----
> > > From: Stuard, Doug
> > > Sent: Tuesday, 8 January 2008 8:20 AM
> > > To: Ted Hardie; Winterbottom, James; Mary Barnes; Arolick, Eric;
> Thomson,
> > > Martin; geopriv@ietf.org
> > > Subject: RE: [Geopriv] Comments on HELD-03
> > >
> > > Perhaps the location returned should be the most recent. Merely
> > accessing
> > > the URI should not re-initiate location determination, as numerous
> > > spurious location taskings could result.  An update should be
> > specifically
> > > requested (although such update could be automated in some
> applications).
> > >
> > > _____________________________________________
> > > Doug Stuard
> > > Andrew Network Services
> > > 19700 Janelia Farm Blvd.
> > > Ashburn, VA 20147
> > > 703-726-5630
> > > (fax) 703-726-5600
> > >
> > > Notice:
> > >
> > > This communication from Andrew Corporation, including attachments,
> > > if any, is intended as a confidential and privileged
communication.
> If
> > > received in error, you should not copy, save, or reproduce in any
> manner
> > > or form, but delete immediately and notify the sender.
> > >
> > > Thank you.
> > >
> > >
> > > > -----Original Message-----
> > > > From: Ted Hardie [mailto:hardie@qualcomm.com]
> > > > Sent: Monday, January 07, 2008 2:21 PM
> > > > To: Winterbottom, James; Mary Barnes; Arolick, Eric; Thomson,
> Martin;
> > > > geopriv@ietf.org
> > > > Subject: RE: [Geopriv] Comments on HELD-03
> > > >
> > > > >[AJW] The Location URIs defined originally for HELD would
always
> > > > return the current location of the Target device, these other
types
> of
> > > > reference had not really been considered. I believe that for
clear
> > > > implementation guidance we need state what the expected
behaviour of
> > > > the reference is. I would propose therefore text something like
the
> > > > following:
> > > > >
> > > > >"The location URI provide the LIS is a current location
reference,
> > and
> > > > the Target Device should assume that the LIS will determine its
> > > > location each time the URI is accessed."
> > > > I don't think this is implementation guidance, so much as
deployment
> > > > guidance
> > > > and I'm somewhat concerned as a result.  I believe, in
particular,
> > that
> > > > "the LIS will determine its location each time the URI is
accessed"
> > > > reflects
> > > > a particular deployment mode.   I think it would be better to
say
> > > > something
> > > > like
> > > >
> > > > "The location URI provided by the LIS is a reference to the most
> > > > current available
> > > > reference, and the Target Device should understand that it is
not a
> > > > stable reference
> > > > to a specific location".
> > > >
> > > > To make the reference as current as possible, the LIS may re-
> determine
> > > > a location
> > > > for the target, but it is possible it will return the freshest
> > > > available data if it
> > > > cannot do so or is configured to treat location requests within
some
> > > > time frame
> > > > able to use previous responses (two dereference request within
the
> > same
> > > > second, for example).
> > > >
> > > > To give a concrete example here, I have in the past made 911
calls
> to
> > > > report
> > > > cars broken down on the highway.  If I made such a call while at
the
> > > > location,
> > > > it would be routed to the correct PSAP (since my car and the
> disabled
> > > > vehicle
> > > > are at the same place).  But if I continue on, my location URI
will
> > get
> > > > updated
> > > > with new locations as I move, and a later dereference will give
a
> > > > different
> > > > location.  We definitely need to make that clear; we may
eventually
> > > > want
> > > > to add functionality to provide a stable reference to a
location,
> > > > for cases where you want to pass both current and stable.
> > > >
> > > > 			regards,
> > > > 				Ted
> > > >
> > > >
> > > > _______________________________________________
> > > > 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