Re: [sipcore] IPv6 in the sip core wg

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 16 December 2013 19:54 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E16D1AC82B for <sipcore@ietfa.amsl.com>; Mon, 16 Dec 2013 11:54:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 WNkPjGFRz7cC for <sipcore@ietfa.amsl.com>; Mon, 16 Dec 2013 11:54:57 -0800 (PST)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id AEE7E1A1F3F for <sipcore@ietf.org>; Mon, 16 Dec 2013 11:54:57 -0800 (PST)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta02.westchester.pa.mail.comcast.net with comcast id 2D2N1n0020vyq2s51Kuw9S; Mon, 16 Dec 2013 19:54:56 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id 2Kuw1n00b3ZTu2S3RKuwY6; Mon, 16 Dec 2013 19:54:56 +0000
Message-ID: <52AF5A90.9020700@alum.mit.edu>
Date: Mon, 16 Dec 2013 14:54:56 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: sipcore@ietf.org
References: <C774C9EA-4E79-4846-A834-BF86D2DD8018@edvina.net> <52A2094E.8020009@alum.mit.edu> <86897DAD-AEAE-4EEC-BCEC-D8501D8491D2@cisco.com> <CAHBDyN7AT0m7P5miYa+hCvh55Ov3f1Nc-U1zUK6H-0i4aHTW+g@mail.gmail.com> <52A7486E.2090005@alum.mit.edu> <FFB57ECD-8CDB-44E9-9A3F-5418AAC01C5B@iii.ca> <26C3B24F-FCBE-4D10-ADD5-E28B6E95A8FB@edvina.net> <BCD747C2-B0E9-492E-97E2-58B078AF5F74@iii.ca> <E9BFFB26-2E71-42D3-A126-0DA7535DD688@edvina.net> <7886ADB0-BDB3-4D15-800B-AAEB34713547@iii.ca> <FD51E29F-9CD3-42F7-B7F6-DB09A60701C9@edvina.net> <52AB353A.9030600@bell-labs.com> <52AB41A2.6070700@alum.mit.edu> <52AB454F.6020105@bell-labs.com>
In-Reply-To: <52AB454F.6020105@bell-labs.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1387223696; bh=1K4c5ut6Xx5aRJ/g/RC/4h3AQKTw/YvVSQ0p+QDRyWk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IOIgZxOQfvtXSnmLadqllmIpqOqzZyJEP9ujHyb7Xqd0VWoyBg9mtLatwmcemdZpj 0uXBZ2pGB7L24S2JRhsFTMNAHZR/rT24cUtY6wMIgDEd+qaS1M4Kh2rhH3pcEcXGri A6OYgrEXbTUMHcz/wn8H80SxzRAiBvtsCnf4QgEm/QlgRqZRcT+gr5qUC/4KlRdOnh /03+N6qaikR933SCeI7yQfQDes7uXHLCX5lIbXdtbMa+kgP73nIn/KwDWRMpj7plIf 66hGn2AQTp8NoailIAp6GwqD9Wdq2K8ENwqx2Ex4Bb30XLwCjarHviK5w4dNm1xgqD pkcZc922CU3Qw==
Subject: Re: [sipcore] IPv6 in the sip core wg
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 16 Dec 2013 19:54:58 -0000

On 12/13/13 12:35 PM, Vijay K. Gurbani wrote:
> On 12/13/2013 11:19 AM, Paul Kyzivat wrote:
> [...]
>> It is a normative statement to use a particular API function as an
>> alternative to a different API function. But there was never a
>> requirement to use "gethostbyname", so the "instead" isn't meaningful,
>> and we shouldn't be requiring use of any particular API functions. It
>> would make a lot more sense if it had a MUST on the algorithms in 3484.
>
> Paul: No doubt true from specifying text in a standards-track RFC, but
> I suspect that most implementors are much more familiar with the
> differences between gethostbyname() and getaddrinfo() than they
> are with the arcana that getaddrinfo() implements rfc3484.

I would not object to this as an implementation note.
But it doesn't seem like a good way to state the normative requirement.

	Thanks,
	Paul

> [...]
>> At the very least, we should include that in the scope of the work.
>> Here is a revised milestone:
>>
>>      May 2014  WGLC of procedures to supplement RFC3263 and RFC6157 for
>>      dual-stack client and server handling of SIP URIs containing domain
>>      names (PS)
>
> Works for me.  Thanks for your time, Paul.
>
> Cheers,
>
> - vijay