IETF Logo Mail Archive

Re: [sipcore] IPv6 in the sip core wg

"Vijay K. Gurbani" <vkg@bell-labs.com> Fri, 13 December 2013 17:35 UTC

Return-Path: <vkg@bell-labs.com>
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 F27AA1AE36F for <sipcore@ietfa.amsl.com>; Fri, 13 Dec 2013 09:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 FNiR2_7ZI9qZ for <sipcore@ietfa.amsl.com>; Fri, 13 Dec 2013 09:35:04 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 29BE91ADF7E for <sipcore@ietf.org>; Fri, 13 Dec 2013 09:35:03 -0800 (PST)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rBDHYt26009330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <sipcore@ietf.org>; Fri, 13 Dec 2013 11:34:55 -0600 (CST)
Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rBDHYt4n022256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <sipcore@ietf.org>; Fri, 13 Dec 2013 11:34:55 -0600
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id rBDHYt2t028523 for <sipcore@ietf.org>; Fri, 13 Dec 2013 11:34:55 -0600 (CST)
Message-ID: <52AB454F.6020105@bell-labs.com>
Date: Fri, 13 Dec 2013 11:35:11 -0600
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
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>
In-Reply-To: <52AB41A2.6070700@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
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: Fri, 13 Dec 2013 17:35:06 -0000

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.

[...]
> 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
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

v2.23.0 | Report a Bug | By Email