RE: [Geopriv] Comments on HELD-03

"Winterbottom, James" <James.Winterbottom@andrew.com> Mon, 07 January 2008 21:28 UTC

Return-path: <geopriv-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBzWY-0004Os-O9; Mon, 07 Jan 2008 16:28:46 -0500
Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1JBzWX-0004N7-Ol for geopriv-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 16:28:45 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBzWX-0004Mz-D4 for geopriv@ietf.org; Mon, 07 Jan 2008 16:28:45 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBzWW-0007mG-Q7 for geopriv@ietf.org; Mon, 07 Jan 2008 16:28:45 -0500
X-SEF-Processed: 5_0_0_910__2008_01_07_15_40_19
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 07 Jan 2008 15:40:19 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jan 2008 15:28:44 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Geopriv] Comments on HELD-03
Date: Mon, 07 Jan 2008 15:28:41 -0600
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF103CA9020@AHQEX1.andrew.com>
In-Reply-To: <E50DB5E7B3006846A8394E3FD5C8D5F10162915D@acvaexch2k3.andrew.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Geopriv] Comments on HELD-03
Thread-Index: AchRYpIrLQFBF8eATnCEHs4hsM3QGQADDy9gAAE7ISA=
References: <E51D5B15BFDEFD448F90BDD17D41CFF103C30057@AHQEX1.andrew.com><A09345776B6C7A4985573569C0F30043171204B2@rrc-dte-exs01.dte.telcordia.com><F66D7286825402429571678A16C2F5EE013A2A62@zrc2hxm1.corp.nortel.com><E51D5B15BFDEFD448F90BDD17D41CFF103CA8AAF@AHQEX1.andrew.com> <p06240608c3a829bb22aa@[129.46.226.27]> <E50DB5E7B3006846A8394E3FD5C8D5F10162915D@acvaexch2k3.andrew.com>
From: "Winterbottom, James" <James.Winterbottom@andrew.com>
To: "Stuard, Doug" <Doug.Stuard@andrew.com>, Ted Hardie <hardie@qualcomm.com>, Mary Barnes <mary.barnes@nortel.com>, "Arolick, Eric" <earolick@telcordia.com>, "Thomson, Martin" <Martin.Thomson@andrew.com>, geopriv@ietf.org
X-OriginalArrivalTime: 07 Jan 2008 21:28:44.0449 (UTC) FILETIME=[47E7D110:01C85174]
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc:
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Errors-To: geopriv-bounces@ietf.org

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