Re: NITs I found while reading the SIP spec

Henning Schulzrinne <hgs@cs.columbia.edu> Sun, 03 May 1998 18:19 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id LAA05325 for confctrl-outgoing; Sun, 3 May 1998 11:19:23 -0700 (PDT)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05320 for <confctrl@zephyr.isi.edu>; Sun, 3 May 1998 11:19:22 -0700 (PDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id LAA05529 for <confctrl@ISI.EDU>; Sun, 3 May 1998 11:19:20 -0700 (PDT)
Received: from leonia (usr44-dialup42.mix2.Boston.mci.net [166.55.77.234]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id OAA21007; Sun, 3 May 1998 14:19:17 -0400 (EDT)
Message-ID: <354CB52A.35B49F00@cs.columbia.edu>
Date: Sun, 03 May 1998 14:19:22 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Reply-To: hgs@cs.columbia.edu
Organization: Columbia University (home)
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: Yaron Goland <yarong@microsoft.com>
CC: "'confctrl@isi.edu'" <confctrl@ISI.EDU>
Subject: Re: NITs I found while reading the SIP spec
X-Priority: 3 (Normal)
References: <3FF8121C9B6DD111812100805F31FC0D029712AA@red-msg-59.dns.microsoft.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Yaron Goland wrote:
> 
> > > Your hostnumber production does not support IPv6
> >
> > Do you have an existing production?
> >
> 
> No, but I'm sure the IPv6 working group can help you. You will need to
> fix
> this in order to survive last call.
> 
Given the wording in draft-fielding-uri-syntax-02.txt:

"Note: A suitable representation for including a literal IPv6
      address as the host part of a URL is desired, but has not yet
      been determined or implemented in practice."

I'm very reluctant to jump in here, given that having a specification
that contradicts the new URL RFC is worse than leaving this open for
now. Based on the RTSP experience, anything that is not an RFC at this
moment cannot make it into the SIP spec for the "proposed" round. This,
for example, precludes any use of the HTTP equivalent of "Require" - we
got badly burned last time (with RTSP) when we assumed that the HTTP
side would be ready in time.

Henning