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

"Elwell, John" <john.elwell@siemens-enterprise.com> Fri, 05 February 2010 16:43 UTC

Return-Path: <john.elwell@siemens-enterprise.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 B770C3A6B15 for <sipping@core3.amsl.com>; Fri, 5 Feb 2010 08:43:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 rZd43p7MGkQU for <sipping@core3.amsl.com>; Fri, 5 Feb 2010 08:43:18 -0800 (PST)
Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A831E3A687B for <sipping@ietf.org>; Fri, 5 Feb 2010 08:43:17 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-796022; Fri, 5 Feb 2010 17:44:08 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 071AD23F0296; Fri, 5 Feb 2010 17:44:08 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 5 Feb 2010 17:44:07 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Date: Fri, 05 Feb 2010 17:44:06 +0100
Thread-Topic: [Sipping] Question on draft-ietf-sipping-v6-transition-07
Thread-Index: AcqmgL6OsSm/efVLQzKI8pw2eEyOHAAASQsw
Message-ID: <A444A0F8084434499206E78C106220CAB9299687@MCHP058A.global-ad.net>
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>
In-Reply-To: <4B6C47FF.2020400@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 16:43:18 -0000

Vijay,

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. This could mean that if you take a single element and use it as input to the DNS mechanism, you get the wrong outcome, and hence including a single element in SDP would be equally wrong. Kevin's message seems to support that belief.

John
 

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] 
> Sent: 05 February 2010 16:32
> To: Elwell, John
> Cc: sipping@ietf.org
> Subject: Re: [Sipping] Question on draft-ietf-sipping-v6-transition-07
> 
> Elwell, John wrote:
> > Thanks, but I was concerned that a domain name beginning with "."
> > might be wrong; Taking the SIP ABNF as an example (SDP ABNF isn't so
> > precise), we have:
> > 
> > hostname         =  *( domainlabel "." ) toplabel [ "." ]
> 
> John: Quite true.  However, in the case we are talking about,
> the ".invalid" appears in the SDP, which is governed by the
> SDP ABNF.  The ".invalid" is not appearing in the URI, but
> in the "c=" line in SDP.
> 
> The SDP ABNF in rfc4566 has this grammar for the
> "c=" line:
> 
> connection-field =    [%x63 "=" nettype SP addrtype SP
>                           connection-address CRLF]
> connection-address =  multicast-address / unicast-address
> unicast-address =     IP4-address / IP6-address / FQDN / extn-addr
> extn-addr =           non-ws-string
> non-ws-string =       1*(VCHAR/%x80-FF)
>                        ;string of visible characters
> 
> Does not ".invalid" in the SDP result from the extn-addr
> production rule above?  Consequently, should it not be legal?
> Or am I missing something here?
> 
> 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/
>