Re: [Geopriv] The 's' in HELD

"Winterbottom, James" <James.Winterbottom@andrew.com> Mon, 05 May 2008 21:40 UTC

Return-Path: <geopriv-bounces@ietf.org>
X-Original-To: geopriv-archive@megatron.ietf.org
Delivered-To: ietfarch-geopriv-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079AA3A6A16; Mon, 5 May 2008 14:40:13 -0700 (PDT)
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327DD28C15C for <geopriv@core3.amsl.com>; Mon, 5 May 2008 14:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.203
X-Spam-Level:
X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2s4HOsqYyeF for <geopriv@core3.amsl.com>; Mon, 5 May 2008 14:40:11 -0700 (PDT)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 07EEC3A68DC for <geopriv@ietf.org>; Mon, 5 May 2008 14:40:10 -0700 (PDT)
X-SEF-Processed: 5_0_0_910__2008_05_05_16_54_00
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, 05 May 2008 16:53:59 -0500
Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 May 2008 16:40:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 05 May 2008 16:40:07 -0500
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF104469416@AHQEX1.andrew.com>
In-Reply-To: <4818B9DF.20402@kyocera-wireless.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Geopriv] The 's' in HELD
Thread-Index: Aciut4re1lNxseRkRHS/FfOvJQhePgAQM20g
References: <E51D5B15BFDEFD448F90BDD17D41CFF10441BD76@AHQEX1.andrew.com><4818B2F8.6090506@bbn.com> <4818B9DF.20402@kyocera-wireless.com>
From: "Winterbottom, James" <James.Winterbottom@andrew.com>
To: Tim Thome <tthome@kyocera-wireless.com>, Richard Barnes <rbarnes@bbn.com>
X-OriginalArrivalTime: 05 May 2008 21:40:09.0558 (UTC) FILETIME=[976B6760:01C8AEF8]
Cc: GEOPRIV <geopriv@ietf.org>, Mary Barnes <mary.barnes@nortel.com>, "Thomson, Martin" <Martin.Thomson@andrew.com>
Subject: Re: [Geopriv] The 's' in HELD
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.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://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: geopriv-bounces@ietf.org
Errors-To: geopriv-bounces@ietf.org

Hi Tim,

I am not sure what you mean by a business relationship with the access
provider. The Target device must have had a sufficient enough
relationship with the access provider that they were able to connect to
the network in the first place. Could you elaborate on your concerns
please?

Cheers
James


> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
Behalf
> Of Tim Thome
> Sent: Thursday, 1 May 2008 4:27 AM
> To: Richard Barnes
> Cc: GEOPRIV; Mary Barnes; Thomson, Martin
> Subject: Re: [Geopriv] The 's' in HELD
> 
> Richard raises a good point, as devices may have requirements for
> emergency contexts... including support for devices that do not have a
> business relationship with the network access and/or service provider.
> 
> Should this context be handled separately?
> 
> Thanks!
> 
> Tim
> 
> Richard Barnes wrote:
> > Is TLS really used for every HELD transaction, as opposed to being
> > available for every transaction?  This seems to be a deviation from
the
> > normal pattern for Internet protocols to have a base protocol
without
> > TLS and an (mandatory) option to use TLS as desired.  More
importantly,
> > it seems like TLS might be undesirable in some circumstances, e.g.,
> > emergency calling.
> >
> > Is there a reason for this extra-strong requirement?
> >
> > --RB
> >
> >
> >
> > Thomson, Martin wrote:
> >
> >> I missed this in the changes for -06.  Please forgive my ignorance,
but
> >> I wasn't there at -71 and it appears that only the conclusion was
> >> captured, not the rationale.  The minutes focus on whether there
should
> >> be a URI scheme or not, but make what seems (to me) to be a logical
> >> leap:
> >>
> >>           Question: Does this HELD: scheme require TLS? Ans: Yes.
Then
> >> it needs
> >>           to be a HELDS: scheme.
> >>
> >> I don't believe that the letter 's' addresses "concerns over
> referential
> >> integrity" as stated by the held-06 change-log.  So can anyone
justify
> >> the above statement?  Is there some IETF guideline I don't know of
that
> >> states that URI schemes for protocols that use TLS have an extra
's'?
> >>
> >> Cheers,
> >> Martin
> >>
> >>
-----------------------------------------------------------------------
> -------------------------
> >> 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]
> >>
> >>
> >>
> 
> --
> Tim Thome - <mailto:tthome@kyocera-wireless.com>
> Senior Staff Engineer
> Technology Development
> Kyocera Wireless Corp.
> San Diego, CA
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.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://www.ietf.org/mailman/listinfo/geopriv