RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

Hadriel Kaplan <HKaplan@acmepacket.com> Thu, 08 April 2010 18:57 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 478253A68E6 for <ietf@core3.amsl.com>; Thu, 8 Apr 2010 11:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.129
X-Spam-Level:
X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.470, 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 ZsDIq0pjPiyL for <ietf@core3.amsl.com>; Thu, 8 Apr 2010 11:57:35 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4F9D23A6ABF for <ietf@ietf.org>; Thu, 8 Apr 2010 11:57:35 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 8 Apr 2010 14:57:30 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 8 Apr 2010 14:57:30 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Richard Shockey <richard@shockey.us>, 'Scott Lawrence' <xmlscott@gmail.com>
Date: Thu, 08 Apr 2010 14:57:29 -0400
Subject: RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Thread-Topic: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Thread-Index: AcrXILPcP1Qtj7B9Rwai+BBZziVwowABX/ZAAAmT2kA=
Message-ID: <430FC6BDED356B4C8498F634416644A91A79F3D32B@mail>
References: <430FC6BDED356B4C8498F634416644A91A79E92FC7@mail> <2AA0BE29-340C-4C8E-8541-087C9A9EE2D2@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CBFD@mail> <1270492215.30814.227.camel@localhost> <430FC6BDED356B4C8498F634416644A91A79F3CC6D@mail> <1270497302.30814.265.camel@localhost> <430FC6BDED356B4C8498F634416644A91A79F3CCE0@mail> <04CD732B-2D7D-45E5-8ED8-A0B27E5BAB8B@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3CE40@mail> <26E13A8A-8E74-40D0-89AA-618546918ACF@cisco.com> <430FC6BDED356B4C8498F634416644A91A79F3D1B9@mail> <1270733844.4307.56.camel@localhost> <000f01cad728$8956a0e0$9c03e2a0$@us>
In-Reply-To: <000f01cad728$8956a0e0$9c03e2a0$@us>
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: 'Cullen Jennings' <fluffy@cisco.com>, 'IETF Discussion Mailing List' <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2010 18:57:36 -0000

> -----Original Message-----
> From: Richard Shockey [mailto:richard@shockey.us]
> Sent: Thursday, April 08, 2010 10:34 AM
> 
> Lets not forget what this specification was attempting to solve, which has
> been the well known boot strap problem with SIP-CUA's we have collectively
> ignored since the creation of SIP, especially those that might use (dare I
> say it) phone numbers. 

I am not forgetting that at all.  That's one of the reasons I find it so perplexing that a draft which is supposed to make things easy and simple for "boot strapping", has decided to mandate a nice-to-have feature which adds complexity and is not required for boot-strapping.  
 

> Any discussion of how to improve the specification is useful but the goal
> is
> the expansion of SIP related services in the market. Gee sort of what we
> are
> trying to do with the PBX to SSP issues.

Right, and as we learned with PBX to SSP issues in SIP-Connect 1.0, not being extremely specific and getting it right the first time will hurt you later. ;)

-hadriel