RE: [Geopriv] Comments on HELD-03

"Thomson, Martin" <Martin.Thomson@andrew.com> Mon, 07 January 2008 22:04 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 1JC04k-0006TI-BR; Mon, 07 Jan 2008 17:04:06 -0500
Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1JC04j-0006T0-2N for geopriv-confirm+ok@megatron.ietf.org; Mon, 07 Jan 2008 17:04:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC04i-0006Ss-Ok for geopriv@ietf.org; Mon, 07 Jan 2008 17:04:04 -0500
Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JC04g-0001Zl-R9 for geopriv@ietf.org; Mon, 07 Jan 2008 17:04:04 -0500
X-SEF-Processed: 5_0_0_910__2008_01_07_16_15_37
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 07 Jan 2008 16:15:37 -0600
Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jan 2008 16:04:02 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Geopriv] Comments on HELD-03
Date: Mon, 07 Jan 2008 16:04:00 -0600
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF103CA9071@AHQEX1.andrew.com>
In-Reply-To: <E51D5B15BFDEFD448F90BDD17D41CFF103CA9020@AHQEX1.andrew.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Geopriv] Comments on HELD-03
Thread-Index: AchRYpIrLQFBF8eATnCEHs4hsM3QGQADDy9gAAE7ISAAAVGqoA==
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> <E51D5B15BFDEFD448F90BDD17D41CFF103CA9020@AHQEX1.andrew.com>
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "Winterbottom, James" <James.Winterbottom@andrew.com>, "Stuard, Doug" <Doug.Stuard@andrew.com>, Ted Hardie <hardie@qualcomm.com>, Mary Barnes <mary.barnes@nortel.com>, "Arolick, Eric" <earolick@telcordia.com>, geopriv@ietf.org
X-OriginalArrivalTime: 07 Jan 2008 22:04:02.0295 (UTC) FILETIME=[363D7870:01C85179]
X-Spam-Score: -0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
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>
Content-Type: multipart/mixed; boundary="===============1899899542=="
Errors-To: geopriv-bounces@ietf.org

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