Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 22 September 2017 13:43 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AED134463 for <sipcore@ietfa.amsl.com>; Fri, 22 Sep 2017 06:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHQ1nniNgrIF for <sipcore@ietfa.amsl.com>; Fri, 22 Sep 2017 06:43:01 -0700 (PDT)
Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id 04E84134467 for <sipcore@ietf.org>; Fri, 22 Sep 2017 06:42:36 -0700 (PDT)
X-AuditID: 1207440c-7e5ff7000000143e-f0-59c5134c90ea
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E1.32.05182.C4315C95; Fri, 22 Sep 2017 09:42:36 -0400 (EDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8MDgYa0011545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 22 Sep 2017 09:42:35 -0400
To: "Jesske, Roland" <R.Jesske@telekom.de>, "Asveren, Tolga" <tasveren@sonusnet.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Cc: James Winterbottom <a.james.winterbottom@gmail.com>
References: <87cf2edcef014e268e000ef358cc3c2c@HE105828.emea1.cds.t-internal.com> <FRAPR01MB04835E32A47072E2DFD00673F9610@FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE> <ec5f0f1b-6739-0ef0-4230-fb459cafdbca@alum.mit.edu> <FRAPR01MB048388505DA606438782090AF9670@FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE> <SN2PR03MB2350D8AA34EBB8364387A340B2670@SN2PR03MB2350.namprd03.prod.outlook.com> <FRAPR01MB0483C947B091A8C2AAD090D3F9670@FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <6e9d3dd7-0c23-2896-8b3b-80bfdd462b92@alum.mit.edu>
Date: Fri, 22 Sep 2017 09:42:34 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <FRAPR01MB0483C947B091A8C2AAD090D3F9670@FRAPR01MB0483.DEUPRD01.PROD.OUTLOOK.DE>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixO6iqOsjfDTS4GeTuMW9TT9ZLJrudLFZ fP2xic1idud7JgcWj52z7rJ7LFnyk8nj0uf/7B5tLxUCWKK4bFJSczLLUov07RK4MvZ9u8pW 8EejouvFa+YGxhcKXYwcHBICJhLb1vJ0MXJxCAnsYJL4/eUMC4TzkEniwIQmNhBHWKCJUeLo xhPMII6IQD+jxOnp75i6GDk5mAXMJZrPdzBCtJxnljh1+AwrSIJNQEtizqH/LCA2r4C9xLu9 08DiLAKqEodmnAaLiwqkSfzbfZYRokZQ4uTMJ2BxToEYiecHj0EtMJOYt/khM4QtLnHryXyo uLxE89bZzBMYBWYhaZ+FpGUWkpZZSFoWMLKsYpRLzCnN1c1NzMwpTk3WLU5OzMtLLdI11MvN LNFLTSndxAgJdp4djN/WyRxiFOBgVOLhNTh4OFKINbGsuDL3EKMkB5OSKG+CwNFIIb6k/JTK jMTijPii0pzU4kOMEhzMSiK8R/8diRTiTUmsrEotyodJSXOwKInzqi5R9xMSSE8sSc1OTS1I LYLJynBwKEnw1gsBDRUsSk1PrUjLzClBSDNxcIIM5wEaHglSw1tckJhbnJkOkT/FqMvR03Pj D5MQS15+XqqUOG8eSJEASFFGaR7cHFiSesUoDvSWMC8XSBUPMMHBTXoFtIQJaEn5apAPiksS EVJSDYxlbiF1K+X1rm+5cDcqzcNSsSL5yIdbYnfitQ++6ryx8uaauty1D/6eYM4VKmDOPqK7 29dc5462iefF+ivpvZO5QkrUtl/dvmH6nrPiC7QWpK++0WTp0VEn7r64qmK6puy7k54dPo/3 l94Tf+bvNGWvyOrGj5JRO81u1x1eFOAr52au4mp3VkiJpTgj0VCLuag4EQDn/O/uLQMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/XDciSXbdiI3LVxrns9T9tjL0n9s>
Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and Liaison Statement to IETF on location source parameter
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Sep 2017 13:43:03 -0000

Roland,

On 9/22/17 5:44 AM, Jesske, Roland wrote:
> Hi,
> so I can let it as it is or add an additional note to mention that the token is for future proof use.
> 
> 
> Also to address Pauls comment complete. I would propose then the following:
> 
> 
>            location-source = "loc-src=" (hostname / other-loc-src)
>            hostname = <defined in RFC3261>
>            other-loc-src = token
> 
>                           Figure 1: Location Source

I'll be ok with this if you also include some text about the intent of 
other-loc-src. Is it intended only as a hook for future extension - 
requiring another document to define that usage? What should a recipient 
do if they receive this with something matching other-loc-src and don't 
understand that usage?

> Thank you and Best regards
> 
> Roland
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Asveren, Tolga [mailto:tasveren@sonusnet.com]
>> Gesendet: Freitag, 22. September 2017 08:24
>> An: Jesske, Roland <R.Jesske@telekom.de>; Paul Kyzivat
>> <pkyzivat@alum.mit.edu>; sipcore@ietf.org
>> Cc: James Winterbottom <a.james.winterbottom@gmail.com>
>> Betreff: RE: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and
>> Liaison Statement to IETF on location source parameter
>>
>> I would prefer to keep the existing syntax. Not that I have an immediate use
>> case at hand but you never know what future would bring. And it would be a
>> pity to have an extension draft just for something like this.
>>
>> Thanks,
>> Tolga
>>
>> -----Original Message-----
>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Jesske, Roland
>> Sent: Friday, September 22, 2017 1:30 AM
>> To: Paul Kyzivat <pkyzivat@alum.mit.edu>; sipcore@ietf.org
>> Cc: James Winterbottom <a.james.winterbottom@gmail.com>
>> Subject: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and
>> Liaison Statement to IETF on location source parameter
>>
>> Hi Paul,
>> Thank you for your comment.
>> The addition of other-loc-src was discussed in the past and was added due to
>> some requests not to restrict this parameter to a hostname.
>> ETSI does only needs a hostname.
>>
>> So I have nothing against to change it as you have proposed it.
>> So If other people would like to keep this please speak up.
>>
>> Thank you and Best Regards
>>
>> Roland
>>
>>
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul
>>> Kyzivat
>>> Gesendet: Mittwoch, 20. September 2017 21:12
>>> An: sipcore@ietf.org
>>> Betreff: Re: [sipcore] draft-winterbottom-sipcore-locparam-01.txt and
>>> Liaison Statement to IETF on location source parameter
>>>
>>> I'm ok with adopting this.
>>>
>>> A minor point on the content:
>>>
>>> The syntax of the new parameter is defined as:
>>>
>>>             location-source = "loc-src=" (host / other-loc-src)
>>>             other-loc-src = token
>>>
>>> But there is no definition of 'host'. I think the definition you are
>>> intending is actually 'hostname' as defined in 3261.
>>>
>>> Also, if "Only a fully qualified host name is valid" then what is the
>>> point of 'other-loc-src'?
>>>
>>> So I would suggest:
>>>
>>>             location-source = "loc-src=" hostname
>>>             hostname = <defined in RFC3261>
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>
>>> On 9/20/17 1:09 AM, Jesske, Roland wrote:
>>>> Dear all,
>>>>
>>>> since I did not get any comments on our draft it look for me that
>>>> people are happy with the content.
>>>>
>>>> So I would like to ask the group for adoption of this draft.
>>>>
>>>> Best Regards
>>>>
>>>> Roland
>>>>
>>>> *Von:*sipcore [mailto:sipcore-bounces@ietf.org] *Im Auftrag von
>>>> *Jesske, Roland
>>>> *Gesendet:* Dienstag, 29. August 2017 10:59
>>>> *An:* sipcore@ietf.org
>>>> *Betreff:* [sipcore] draft-winterbottom-sipcore-locparam-01.txt and
>>>> Liaison Statement to IETF on location source parameter
>>>>
>>>> Dear all,
>>>>
>>>> since I have uploaded the latest draft on
>>>> draft-winterbottom-sipcore-locparam-01.txt and the last
>>>> clarification on questions were given on 23. May I did not get any further
>> comment.
>>>>
>>>> With a reference to this draft a Liaison from ETSI (
>>>> https://datatracker.ietf.org/liaison/1527/ ) is waiting for action.
>>>>
>>>> The liaison from ETSI is asking on the progress of the draft for
>>>> their solution on Emergency Call due to the Project of  the European
>>>> Union
>>>> Mandate: M493.
>>>>
>>>> My question is, since we have no open questions, if we can now
>>>> progress the draft.
>>>>
>>>> Thank you for consideration.
>>>>
>>>> Best Regards
>>>>
>>>> Roland
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> sipcore@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
> 
>