RE: WG Review: Call Control UUI for SIP (cuss)

"WORLEY, Dale R (Dale)" <dworley@avaya.com> Tue, 29 June 2010 17:10 UTC

Return-Path: <dworley@avaya.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 D10F63A697F; Tue, 29 Jun 2010 10:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.031
X-Spam-Level:
X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=0.568, 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 ev8RnP237Ybg; Tue, 29 Jun 2010 10:10:53 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 238503A6AD3; Tue, 29 Jun 2010 10:10:50 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,505,1272859200"; d="scan'208";a="195786963"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 Jun 2010 13:11:00 -0400
X-IronPort-AV: E=Sophos;i="4.53,505,1272859200"; d="scan'208";a="477060419"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 29 Jun 2010 13:10:59 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 29 Jun 2010 13:10:59 -0400
From: "WORLEY, Dale R (Dale)" <dworley@avaya.com>
To: Cullen Jennings <fluffy@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>
Date: Tue, 29 Jun 2010 13:10:00 -0400
Subject: RE: WG Review: Call Control UUI for SIP (cuss)
Thread-Topic: WG Review: Call Control UUI for SIP (cuss)
Thread-Index: AcsW7ytWkKrZuAwcSL+Jm+RlBXipvgAvry3w
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21FE98EE2E@DC-US1MBEX4.global.avaya.com>
References: <20100622170002.02B053A683E@core3.amsl.com>, <74B1068E-86C0-426E-8E9B-841C23EE9965@cisco.com>
In-Reply-To: <74B1068E-86C0-426E-8E9B-841C23EE9965@cisco.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: 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: Tue, 29 Jun 2010 17:10:55 -0000

ietf-bounces@ietf.org [ietf-bounces@ietf.org] on behalf of Cullen Jennings [fluffy@cisco.com]
> As far as I can tell, the WG says they wants to transfer some
> information to achieve cross vendor interoperability. However, what I
> believe the charter is actually going to do is exactly the opposite of
> that. When you get your head around what this charter is proposing, it
> is going to form a more or less opaque container for transporting
> proprietary information in a SIP header. It's hard to imagine how this
> will help interoperability.

It depends on how you look at it.  E.g., one can look at TCP as being
a "more or less opaque container for transporting proprietary
information".  The critical question is whether the information is
stuff that the IETF wants to standardize.

As far as I can tell, ISDN provides a specific endpoint-to-endpoint
opaque transport that this charter seeks to imitate.  That the
carried information is proprietary is important only if we wish to
standardize the endpoint interactions in question.

The charter seems to demand that the SIP mechanism would at least tag
the transported information:

> > User data of the mechanism will be clearly marked with the
> > application, encoding, semantics, and content type, allowing policy to
> > be applied by UAs.  The working group will define the information that
> > each application must specify to utilize the mechanism. This type of
> > application-specific information will be specified in standards-track
> > documents.

This seems to be a step more open than the current ISDN facility.

Dale