Re: [Sipping] Question on draft-ietf-sipping-v6-transition-07

"Vijay K. Gurbani" <vkg@alcatel-lucent.com> Fri, 05 February 2010 17:14 UTC

Return-Path: <vkg@alcatel-lucent.com>
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744013A6944 for <sipping@core3.amsl.com>; Fri, 5 Feb 2010 09:14:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level:
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599]
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 qAguQmtKEIKq for <sipping@core3.amsl.com>; Fri, 5 Feb 2010 09:14:41 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 0F0B93A6AFB for <sipping@ietf.org>; Fri, 5 Feb 2010 09:14:38 -0800 (PST)
Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o15HFQMZ027954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 11:15:26 -0600 (CST)
Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o15HFPjV026235; Fri, 5 Feb 2010 11:15:25 -0600 (CST)
Message-ID: <4B6C522D.3020901@alcatel-lucent.com>
Date: Fri, 05 Feb 2010 11:15:25 -0600
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Elwell, John" <john.elwell@siemens-enterprise.com>
References: <A444A0F8084434499206E78C106220CAB4EC49D8@MCHP058A.global-ad.net> <4B61E8AE.6090309@alcatel-lucent.com> <A444A0F8084434499206E78C106220CAB4EC49F5@MCHP058A.global-ad.net> <4B61EEFE.3030605@alcatel-lucent.com> <A444A0F8084434499206E78C106220CAB920FE16@MCHP058A.global-ad.net> <4B6B2FF0.5030007@bell-labs.com> <A444A0F8084434499206E78C106220CAB9210933@MCHP058A.global-ad.net> <4B6C47FF.2020400@alcatel-lucent.com> <A444A0F8084434499206E78C106220CAB9299687@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CAB9299687@MCHP058A.global-ad.net>
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
Cc: "sipping@ietf.org" <sipping@ietf.org>
Subject: Re: [Sipping] Question on draft-ietf-sipping-v6-transition-07
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2010 17:14:42 -0000

Elwell, John wrote:
> Yes, I know we are talking SDP, but the SDP ABNF was so imprecise
> that I looked elsewhere. I am not sure where the definitive source
> is, but I just took SIP as an example, which seemed to suggest that
> the people who wrote RFC 3261 thought that a single element (without
> any dot) was wrong. 

John: I would believe the authors of rfc3261 focused on
the signaling itself and relegated the nuances of body handling
to appropriate mechanisms and documents.  We should probably
seek their opinion.

That said, I am not refuting your or Kevin's stance.  Clearly,
implementers opt for the path of least resistance, and this
dictates that they parse the token from SDP "c=" line and feed
it directly into the DNS routines (which will certainly hiccup
when given ".invalid").  However, pedantically speaking, the SDP
ABNF seems to indicate that ".invalid" is legal (at least to my
reading.)

Thus, when a developer armed with the pedantic interpretation
squares off against a developer armed with an implementation
that took the path of least resistance, who is right?  I am
sure you have been part of countless arguments where standards
say one thing and what is implemented is a bit ... well ...
different ;-)

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/