From brett@broadsoft.com Tue Oct 1 07:45:55 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AC021F9FE7 for ; Tue, 1 Oct 2013 07:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G5hB6eLgxnp for ; Tue, 1 Oct 2013 07:45:49 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 9944521F9FDA for ; Tue, 1 Oct 2013 07:45:49 -0700 (PDT) Received: from CASUMHUB05.citservers.local (172.16.98.229) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 1 Oct 2013 07:46:47 -0700 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by casumhub05.citservers.local ([::1]) with mapi id 14.02.0247.003; Tue, 1 Oct 2013 07:46:47 -0700 From: Brett Tate To: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" , "sipcore@ietf.org" Thread-Topic: draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility Thread-Index: Ac6+tOnasetgJzQqTqaWpWJO3jXdMw== Date: Tue, 1 Oct 2013 14:46:47 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 14:45:55 -0000 Hi, The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-targeted-to-uri is not ba= ckwards compatible with RFC 4244. Is this intentional? And if so, should it be mentioned within section 16 a= nd/or 16.1? Thanks, Brett ----- draft-ietf-sipcore-rfc4244bis-11: History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-entry) hi-entry =3D hi-targeted-to-uri *(SEMI hi-param) hi-targeted-to-uri =3D addr-spec / name-addr RFC 4244: History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-entry) hi-entry =3D hi-targeted-to-uri *( SEMI hi-param ) hi-targeted-to-uri=3D name-addr This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it. From mary.ietf.barnes@gmail.com Tue Oct 1 10:41:20 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1545921F9DD6 for ; Tue, 1 Oct 2013 10:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAV0hNhBJKlu for ; Tue, 1 Oct 2013 10:41:19 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id C0CC511E8153 for ; Tue, 1 Oct 2013 10:41:16 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id ii20so3572508qab.7 for ; Tue, 01 Oct 2013 10:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3uZDbEphJ2BDN6/t8T22c2QaiJD0//INxXlyBMYWtdI=; b=uoUrfK3m5UhVd9yQNxNB34/F3Y5irE0dsi9LE8PUqLZ1m+EH29NLbqeRK8dwDcLKVE h+LhgS+78ULSc9FgKg1AdCM+vid9gSPk334kvtuHdCfLGm0p3YjPAZb+iOE9Q1xoTu9q VpDf0zSytQMEvm5qggTHLPCypporb4OlJuedsEAiK2BwPJkSwGKxl98wesJvGc1fP5iR 0kNOWR68rNyNb2WWhPuWHTJoK9OPedgUulVC5w7xZz/9adsBK92o/3rL0J84Gmgo+alQ 71y+de63v/SoYvGUYQakikRQkHL1u9q9CUDyUenK31WmI25/qMcWIEjHpn9VZAp/+Z+f 62/g== MIME-Version: 1.0 X-Received: by 10.224.96.137 with SMTP id h9mr11272295qan.96.1380649276223; Tue, 01 Oct 2013 10:41:16 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 1 Oct 2013 10:41:16 -0700 (PDT) In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> Date: Tue, 1 Oct 2013 12:41:16 -0500 Message-ID: From: Mary Barnes To: Brett Tate Content-Type: multipart/alternative; boundary=001a11c2e0a8ab39b204e7b175b4 Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 17:41:20 -0000 --001a11c2e0a8ab39b204e7b175b4 Content-Type: text/plain; charset=ISO-8859-1 I don't think it was intentional. I backtracked and for whatever reason that change appeared in the individual -00 and I could find no email threads as to why we would have made that change. It appears Dale pointed out that issue a long time back, as well, but it seems we didn't make that fix. So, that is an error and we should fix that. We have a couple other editorial/clarification points that Dale has pointed out that we will also include in a revision shortly. Thanks, Mary. On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate wrote: > Hi, > > The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-targeted-to-uri is not > backwards compatible with RFC 4244. > > Is this intentional? And if so, should it be mentioned within section 16 > and/or 16.1? > > Thanks, > Brett > > ----- > > draft-ietf-sipcore-rfc4244bis-11: > > History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) > > hi-entry = hi-targeted-to-uri *(SEMI hi-param) > > hi-targeted-to-uri = addr-spec / name-addr > > > RFC 4244: > > History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) > > hi-entry = hi-targeted-to-uri *( SEMI hi-param ) > > hi-targeted-to-uri= name-addr > > This email is intended solely for the person or entity to which it is > addressed and may contain confidential and/or privileged information. If > you are not the intended recipient and have received this email in error, > please notify BroadSoft, Inc. immediately by replying to this message, and > destroy all copies of this message, along with any attachment, prior to > reading, distributing or copying it. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11c2e0a8ab39b204e7b175b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't think it was intentional. =A0I backtracked and= for whatever reason that change appeared in the individual -00 and I could= find no email threads as to why we would have made that change. =A0 It app= ears Dale pointed out that issue a long time back, as well, but it seems we= didn't make that fix. =A0

So, that is an error and we should fix that. =A0We have a co= uple other editorial/clarification points that Dale has pointed out that we= will also include in a revision shortly.

Thanks,<= /div>
Mary.=A0


On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate &l= t;brett@broadsoft.= com> wrote:
Hi,

The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-targeted-to-uri is no= t backwards compatible with RFC 4244.

Is this intentional? =A0And if so, should it be mentioned within section 16= and/or 16.1?

Thanks,
Brett

-----

draft-ietf-sipcore-rfc4244bis-11:

=A0 History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-en= try)

=A0 hi-entry =3D hi-targeted-to-uri *(SEMI hi-param)

=A0 hi-targeted-to-uri =3D addr-spec / name-addr


RFC 4244:

=A0 History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-en= try)

=A0 hi-entry =3D hi-targeted-to-uri *( SEMI hi-param )

=A0 hi-targeted-to-uri=3D name-addr

This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it.
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--001a11c2e0a8ab39b204e7b175b4-- From francois.audet@skype.net Tue Oct 1 10:47:29 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A5E11E8153 for ; Tue, 1 Oct 2013 10:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnlC9guCCAvG for ; Tue, 1 Oct 2013 10:47:23 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.27]) by ietfa.amsl.com (Postfix) with ESMTP id BDC3721E805F for ; Tue, 1 Oct 2013 10:47:17 -0700 (PDT) Received: from BY2SR01CA104.namsdf01.sdf.exchangelabs.com (10.255.93.149) by BY2SR01MB609.namsdf01.sdf.exchangelabs.com (10.255.93.168) with Microsoft SMTP Server (TLS) id 15.0.800.2; Tue, 1 Oct 2013 17:47:14 +0000 Received: from BY1FFOFD001.ffo.gbl (64.4.22.90) by BY2SR01CA104.outlook.office365.com (10.255.93.149) with Microsoft SMTP Server (TLS) id 15.0.800.2 via Frontend Transport; Tue, 1 Oct 2013 17:47:14 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.17) by BY1FFOFD001.mail.o365filtering.com (10.1.16.83) with Microsoft SMTP Server (TLS) id 15.0.795.3 via Frontend Transport; Tue, 1 Oct 2013 17:47:14 +0000 Received: from DFM-TK5MBX15-03.exchange.corp.microsoft.com (157.54.110.22) by DF-G14-01.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 14.3.123.1; Tue, 1 Oct 2013 17:46:54 +0000 Received: from DFM-DB3MBX15-08.exchange.corp.microsoft.com (10.166.18.226) by DFM-TK5MBX15-03.exchange.corp.microsoft.com (157.54.110.22) with Microsoft SMTP Server (TLS) id 15.0.775.14; Tue, 1 Oct 2013 10:46:41 -0700 Received: from DFM-DB3MBX15-06.exchange.corp.microsoft.com (10.166.18.224) by DFM-DB3MBX15-08.exchange.corp.microsoft.com (10.166.18.226) with Microsoft SMTP Server (TLS) id 15.0.775.14; Tue, 1 Oct 2013 10:46:27 -0700 Received: from DFM-DB3MBX15-06.exchange.corp.microsoft.com ([10.166.18.224]) by DFM-DB3MBX15-06.exchange.corp.microsoft.com ([169.254.10.253]) with mapi id 15.00.0775.014; Tue, 1 Oct 2013 10:46:27 -0700 From: Francois Audet To: Mary Barnes , Brett Tate Thread-Topic: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility Thread-Index: AQHOvs2LaFm4ZTyhCE6+C75znn+hHpngHpCg Date: Tue, 1 Oct 2013 17:46:26 +0000 Message-ID: <620020d3b4ca4d2fad8e7ad55a290f41@DFM-DB3MBX15-06.exchange.corp.microsoft.com> References: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.13] Content-Type: multipart/alternative; boundary="_000_620020d3b4ca4d2fad8e7ad55a290f41DFMDB3MBX1506exchangeco_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.17; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(164054003)(24454002)(199002)(189002)(377454003)(56776001)(54316002)(49866001)(66066001)(31966008)(71186001)(80022001)(47446002)(74502001)(46102001)(50986001)(47736001)(47976001)(59766001)(19580395003)(512954002)(81686001)(6806004)(79102001)(80976001)(65816001)(20776003)(84326002)(15975445006)(63696002)(81342001)(76482001)(69226001)(81542001)(33646001)(76786001)(74706001)(81816001)(74876001)(53806001)(74662001)(74366001)(56816003)(83072001)(4396001)(77982001)(83322001)(19580405001)(54356001)(51856001)(44976005)(16236675003)(15202345003)(19300405004)(76796001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2SR01MB609; H:hybrid.exchange.microsoft.com; CLIP:131.107.1.17; FPR:; RD:mail1.exchange.microsoft.com; A:1; MX:1; LANG:en; X-Forefront-PRVS: 09860C2161 X-OriginatorOrg: msft.ccsctp.net Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 17:47:29 -0000 --_000_620020d3b4ca4d2fad8e7ad55a290f41DFMDB3MBX1506exchangeco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It does indeed look like an error to be fixed. From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Mary Barnes Sent: Tuesday, October 1, 2013 10:41 AM To: Brett Tate Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward comp= atibility I don't think it was intentional. I backtracked and for whatever reason th= at change appeared in the individual -00 and I could find no email threads = as to why we would have made that change. It appears Dale pointed out tha= t issue a long time back, as well, but it seems we didn't make that fix. So, that is an error and we should fix that. We have a couple other editor= ial/clarification points that Dale has pointed out that we will also includ= e in a revision shortly. Thanks, Mary. On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate > wrote: Hi, The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-targeted-to-uri is not ba= ckwards compatible with RFC 4244. Is this intentional? And if so, should it be mentioned within section 16 a= nd/or 16.1? Thanks, Brett ----- draft-ietf-sipcore-rfc4244bis-11: History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-entry) hi-entry =3D hi-targeted-to-uri *(SEMI hi-param) hi-targeted-to-uri =3D addr-spec / name-addr RFC 4244: History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-entry) hi-entry =3D hi-targeted-to-uri *( SEMI hi-param ) hi-targeted-to-uri=3D name-addr This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_620020d3b4ca4d2fad8e7ad55a290f41DFMDB3MBX1506exchangeco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It does indeed look like = an error to be fixed.

 

From: sipcor= e-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Tuesday, October 1, 2013 10:41 AM
To: Brett Tate
Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backwa= rd compatibility

 

I don't think it was intentional.  I backtracke= d and for whatever reason that change appeared in the individual -00 and I = could find no email threads as to why we would have made that change.  = ; It appears Dale pointed out that issue a long time back, as well, but it seems we didn't make that fix.  

 

So, that is an error and we should fix that.  W= e have a couple other editorial/clarification points that Dale has pointed = out that we will also include in a revision shortly.

 

Thanks,

Mary. 

 

On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate <brett@broadsoft.com= > wrote:

Hi,

The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-targeted-to-uri is not ba= ckwards compatible with RFC 4244.

Is this intentional?  And if so, should it be mentioned within section= 16 and/or 16.1?

Thanks,
Brett

-----

draft-ietf-sipcore-rfc4244bis-11:

  History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi= -entry)

  hi-entry =3D hi-targeted-to-uri *(SEMI hi-param)

  hi-targeted-to-uri =3D addr-spec / name-addr


RFC 4244:

  History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi= -entry)

  hi-entry =3D hi-targeted-to-uri *( SEMI hi-param )

  hi-targeted-to-uri=3D name-addr

This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along= with any attachment, prior to reading, distributing or copying it.
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

 

--_000_620020d3b4ca4d2fad8e7ad55a290f41DFMDB3MBX1506exchangeco_-- From brett@broadsoft.com Tue Oct 1 11:25:23 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B20321F9DAF for ; Tue, 1 Oct 2013 11:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flzkM8G3lZhA for ; Tue, 1 Oct 2013 11:25:19 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id F123321F9DA8 for ; Tue, 1 Oct 2013 11:25:18 -0700 (PDT) Received: from CASUMHUB05.citservers.local (172.16.98.229) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 1 Oct 2013 11:26:17 -0700 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by casumhub05.citservers.local ([::1]) with mapi id 14.02.0247.003; Tue, 1 Oct 2013 11:26:17 -0700 From: Brett Tate To: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility Thread-Index: AQHOvs2SCjLCpQxSiEm3Y+LPiDjPAZngJOEg Date: Tue, 1 Oct 2013 18:26:15 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A061FED@MBX08.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: multipart/alternative; boundary="_000_576A8B541C219D4E9CEB1DF8C19C7B881A061FEDMBX08citservers_" MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:25:23 -0000 --_000_576A8B541C219D4E9CEB1DF8C19C7B881A061FEDMBX08citservers_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mary, It looks like Dale requested the change; however, I think that it will caus= e interoperability issues with rfc4244 devices if an rfc4244bis devices sen= ds an addr-spec. Thus I think that the change should be reverted (to be hi= -targeted-to-uri=3D name-addr). http://www.ietf.org/mail-archive/web/sipcore/current/msg04158.html Thanks, Brett From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Tuesday, October 01, 2013 1:41 PM To: Brett Tate Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward comp= atibility I don't think it was intentional. I backtracked and for whatever reason th= at change appeared in the individual -00 and I could find no email threads = as to why we would have made that change. It appears Dale pointed out tha= t issue a long time back, as well, but it seems we didn't make that fix. So, that is an error and we should fix that. We have a couple other editor= ial/clarification points that Dale has pointed out that we will also includ= e in a revision shortly. Thanks, Mary. On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate > wrote: Hi, The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-targeted-to-uri is not ba= ckwards compatible with RFC 4244. Is this intentional? And if so, should it be mentioned within section 16 a= nd/or 16.1? Thanks, Brett ----- draft-ietf-sipcore-rfc4244bis-11: History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-entry) hi-entry =3D hi-targeted-to-uri *(SEMI hi-param) hi-targeted-to-uri =3D addr-spec / name-addr RFC 4244: History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-entry) hi-entry =3D hi-targeted-to-uri *( SEMI hi-param ) hi-targeted-to-uri=3D name-addr This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_576A8B541C219D4E9CEB1DF8C19C7B881A061FEDMBX08citservers_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mary,

 <= /p>

It looks like Dale reques= ted the change; however, I think that it will cause interoperability issues= with rfc4244 devices if an rfc4244bis devices sends an addr-spec.  Thus I think that the change should be reverted (to be hi= -targeted-to-uri=3D name-addr).

 <= /p>

http://www.ietf.org/m= ail-archive/web/sipcore/current/msg04158.html

 <= /p>

Thanks,=

Brett

 <= /p>

From: Mary Bar= nes [mailto:mary.ietf.barnes@gmail.com]
Sent: Tuesday, October 01, 2013 1:41 PM
To: Brett Tate
Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backwa= rd compatibility

 

I don't think it was intentional.  I backtracke= d and for whatever reason that change appeared in the individual -00 and I = could find no email threads as to why we would have made that change.  = ; It appears Dale pointed out that issue a long time back, as well, but it seems we didn't make that fix.  

 

So, that is an error and we should fix that.  W= e have a couple other editorial/clarification points that Dale has pointed = out that we will also include in a revision shortly.

 

Thanks,

Mary. 

 

On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate <brett@broadsoft.com= > wrote:

Hi,

The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-targeted-to-uri is not ba= ckwards compatible with RFC 4244.

Is this intentional?  And if so, should it be mentioned within section= 16 and/or 16.1?

Thanks,
Brett

-----

draft-ietf-sipcore-rfc4244bis-11:

  History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi= -entry)

  hi-entry =3D hi-targeted-to-uri *(SEMI hi-param)

  hi-targeted-to-uri =3D addr-spec / name-addr


RFC 4244:

  History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi= -entry)

  hi-entry =3D hi-targeted-to-uri *( SEMI hi-param )

  hi-targeted-to-uri=3D name-addr

This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along= with any attachment, prior to reading, distributing or copying it.
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

 

--_000_576A8B541C219D4E9CEB1DF8C19C7B881A061FEDMBX08citservers_-- From mary.ietf.barnes@gmail.com Tue Oct 1 11:38:39 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FB111E81B9 for ; Tue, 1 Oct 2013 11:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyuWXQN+jjia for ; Tue, 1 Oct 2013 11:38:38 -0700 (PDT) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1F00211E820F for ; Tue, 1 Oct 2013 11:38:36 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 6so5285747qea.4 for ; Tue, 01 Oct 2013 11:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fdp+lprkxqAfWl2xADVXV7z/wF0UblO5MDx7bd6/Dq8=; b=IubPxl7FCXyWAGdZdK96pIkD0mSVRXnw6kgNEKqFP2KTlyiNZqJVXEs/ZPDJn9pfXJ 1gNaeibgJWtpAvFSMnzvoh8yffFEEz7gTmz0L7ID2nqiLMWwX5s/vhNafINYM6gidsgP WY8MDebn94kSAwdlQeMcS+y6PpcHIb6Sv0pkNtzKQZlLwjOiRI6uK+HiLO+Bc0i0Naz2 VZMucVYNAIpz3QddjV8NjQlyrw6qp1/Qhp75/g2o6Zsu7KbY9yqkaT3ffcI/d460MWsw HWQNZD0DIdThHkT50A1iadjNs6G/QCewUBugkJyYSHfaNoiVsksXqxnX9dDFEVEUaGiv v5XA== MIME-Version: 1.0 X-Received: by 10.49.35.106 with SMTP id g10mr38125701qej.35.1380652716523; Tue, 01 Oct 2013 11:38:36 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 1 Oct 2013 11:38:36 -0700 (PDT) In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A061FED@MBX08.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> <576A8B541C219D4E9CEB1DF8C19C7B881A061FED@MBX08.citservers.local> Date: Tue, 1 Oct 2013 13:38:36 -0500 Message-ID: From: Mary Barnes To: Brett Tate Content-Type: multipart/alternative; boundary=047d7b6766f8ba097704e7b2427b Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:38:39 -0000 --047d7b6766f8ba097704e7b2427b Content-Type: text/plain; charset=ISO-8859-1 Yes, you are correct - I misread the diffs and we did make the change based on Dale's comment, but we (authors) agree that it should be consistent with RFC 4244. Mary. On Tue, Oct 1, 2013 at 1:26 PM, Brett Tate wrote: > Hi Mary,**** > > ** ** > > It looks like Dale requested the change; however, I think that it will > cause interoperability issues with rfc4244 devices if an rfc4244bis devices > sends an addr-spec. Thus I think that the change should be reverted (to be > hi-targeted-to-uri= name-addr).**** > > ** ** > > http://www.ietf.org/mail-archive/web/sipcore/current/msg04158.html **** > > ** ** > > Thanks,**** > > Brett**** > > ** ** > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Tuesday, October 01, 2013 1:41 PM > > *To:* Brett Tate > *Cc:* draft-ietf-sipcore-rfc4244bis@tools.ietf.org; sipcore@ietf.org > *Subject:* Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward > compatibility**** > > ** ** > > I don't think it was intentional. I backtracked and for whatever reason > that change appeared in the individual -00 and I could find no email > threads as to why we would have made that change. It appears Dale pointed > out that issue a long time back, as well, but it seems we didn't make that > fix. **** > > ** ** > > So, that is an error and we should fix that. We have a couple other > editorial/clarification points that Dale has pointed out that we will also > include in a revision shortly.**** > > ** ** > > Thanks,**** > > Mary. **** > > ** ** > > On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate wrote:*** > * > > Hi, > > The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-targeted-to-uri is not > backwards compatible with RFC 4244. > > Is this intentional? And if so, should it be mentioned within section 16 > and/or 16.1? > > Thanks, > Brett > > ----- > > draft-ietf-sipcore-rfc4244bis-11: > > History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) > > hi-entry = hi-targeted-to-uri *(SEMI hi-param) > > hi-targeted-to-uri = addr-spec / name-addr > > > RFC 4244: > > History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) > > hi-entry = hi-targeted-to-uri *( SEMI hi-param ) > > hi-targeted-to-uri= name-addr > > This email is intended solely for the person or entity to which it is > addressed and may contain confidential and/or privileged information. If > you are not the intended recipient and have received this email in error, > please notify BroadSoft, Inc. immediately by replying to this message, and > destroy all copies of this message, along with any attachment, prior to > reading, distributing or copying it. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore**** > > ** ** > --047d7b6766f8ba097704e7b2427b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, you are correct - I misread the diffs and we did make= the change based on Dale's comment, but we (authors) agree that it sho= uld be consistent with RFC 4244.

Mary.=A0


On Tue, Oct 1, 2013 at 1:26 PM, Brett Ta= te <brett@broadsoft.com> wrote:

Hi Mary,

=A0<= /p>

It looks like Dale reques= ted the change; however, I think that it will cause interoperability issues= with rfc4244 devices if an rfc4244bis devices sends an addr-spec.=A0 Thus I think that the change should be reverted (to be hi-ta= rgeted-to-uri=3D name-addr).

=A0<= /p>

htt= p://www.ietf.org/mail-archive/web/sipcore/current/msg04158.html

=A0<= /p>

Thanks,

Brett

=A0<= /p>

From: Mary Bar= nes [mailto:mary.ietf.barnes@gmail.com]
Sent: Tuesday, October 01, 2013 1:41 PM

=
To: Brett Tate
Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; sipcore@ietf.org
Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backwa= rd compatibility

=A0

I don't think it was intentional. =A0I backtrack= ed and for whatever reason that change appeared in the individual -00 and I= could find no email threads as to why we would have made that change. =A0 = It appears Dale pointed out that issue a long time back, as well, but it seems we didn't make that fix. =A0

=A0

So, that is an error and we should fix that. =A0We h= ave a couple other editorial/clarification points that Dale has pointed out= that we will also include in a revision shortly.

=A0

Thanks,

Mary.=A0

=A0

On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate <brett@broadsoft.com= > wrote:

Hi,

The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-targeted-to-uri is no= t backwards compatible with RFC 4244.

Is this intentional? =A0And if so, should it be mentioned within section 16= and/or 16.1?

Thanks,
Brett

-----

draft-ietf-sipcore-rfc4244bis-11:

=A0 History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-en= try)

=A0 hi-entry =3D hi-targeted-to-uri *(SEMI hi-param)

=A0 hi-targeted-to-uri =3D addr-spec / name-addr


RFC 4244:

=A0 History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-en= try)

=A0 hi-entry =3D hi-targeted-to-uri *( SEMI hi-param )

=A0 hi-targeted-to-uri=3D name-addr

This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along= with any attachment, prior to reading, distributing or copying it.
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

=A0


--047d7b6766f8ba097704e7b2427b-- From pkyzivat@alum.mit.edu Tue Oct 1 12:54:11 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08B511E8153 for ; Tue, 1 Oct 2013 12:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.162 X-Spam-Level: ** X-Spam-Status: No, score=2.162 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLyUZBeAEPmI for ; Tue, 1 Oct 2013 12:53:59 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 886A121E805F for ; Tue, 1 Oct 2013 12:53:25 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta10.westchester.pa.mail.comcast.net with comcast id Xtz21m00v16LCl05AvtQX8; Tue, 01 Oct 2013 19:53:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id XvtQ1m00C3ZTu2S3SvtQsh; Tue, 01 Oct 2013 19:53:24 +0000 Message-ID: <524B2832.9040201@alum.mit.edu> Date: Tue, 01 Oct 2013 15:53:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sipcore@ietf.org References: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> <576A8B541C219D4E9CEB1DF8C19C7B881A061FED@MBX08.citservers.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380657204; bh=JAchbATgoAE1O6Eli2G2niwi+kONT/9QxqUyZE8C9/8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=o2e+QmOPfE6MOUtfDIVzRfbzN0lsEjlqZuSt6XnCl5MixBaqg2zUKL8MS/ilL6sT3 DFldRqVpeT72g4DhldFOv/QxDsjROWw0io7VxO+pjT/bH6Smal6TEy3go4l6V6Q7s8 dtMCoKT40Uw7PpVXgi5phpausxcIFgYhEycftG8XedHTzJ0x4M4FN13jytTnV8xXuM 1dm1Uw14s4WPErrPiU8jcQIsivL69NprnDNpWDYj7RMPbB1PxEDsSqohOxo7M7u+LB mc6N9hBbZ6FTvoTTST4juwSWb6eAd/hGB3174o3yjf6ED+OAzCaCAxe0pz+H9x6Etv XiCDta/VZZpHw== Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 19:54:11 -0000 IIUC, the change was to permit addr-spec as well as name-addr. And this issue is then that a 4244 implementation won't be able to parse that. Right? Please ensure that the use cases are still correct after the change. Thanks, Paul On 10/1/13 2:38 PM, Mary Barnes wrote: > Yes, you are correct - I misread the diffs and we did make the change > based on Dale's comment, but we (authors) agree that it should be > consistent with RFC 4244. > > Mary. > > > On Tue, Oct 1, 2013 at 1:26 PM, Brett Tate > wrote: > > Hi Mary,____ > > __ __ > > It looks like Dale requested the change; however, I think that it > will cause interoperability issues with rfc4244 devices if an > rfc4244bis devices sends an addr-spec. Thus I think that the change > should be reverted (to be hi-targeted-to-uri= name-addr).____ > > __ __ > > http://www.ietf.org/mail-archive/web/sipcore/current/msg04158.html ____ > > __ __ > > Thanks,____ > > Brett____ > > __ __ > > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com > ] > *Sent:* Tuesday, October 01, 2013 1:41 PM > > > *To:* Brett Tate > *Cc:* draft-ietf-sipcore-rfc4244bis@tools.ietf.org > ; > sipcore@ietf.org > *Subject:* Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF > backward compatibility____ > > __ __ > > I don't think it was intentional. I backtracked and for whatever > reason that change appeared in the individual -00 and I could find > no email threads as to why we would have made that change. It > appears Dale pointed out that issue a long time back, as well, but > it seems we didn't make that fix. ____ > > __ __ > > So, that is an error and we should fix that. We have a couple other > editorial/clarification points that Dale has pointed out that we > will also include in a revision shortly.____ > > __ __ > > Thanks,____ > > Mary. ____ > > __ __ > > On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate > wrote:____ > > Hi, > > The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-targeted-to-uri is > not backwards compatible with RFC 4244. > > Is this intentional? And if so, should it be mentioned within > section 16 and/or 16.1? > > Thanks, > Brett > > ----- > > draft-ietf-sipcore-rfc4244bis-11: > > History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) > > hi-entry = hi-targeted-to-uri *(SEMI hi-param) > > hi-targeted-to-uri = addr-spec / name-addr > > > RFC 4244: > > History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) > > hi-entry = hi-targeted-to-uri *( SEMI hi-param ) > > hi-targeted-to-uri= name-addr > > This email is intended solely for the person or entity to which it > is addressed and may contain confidential and/or privileged > information. If you are not the intended recipient and have received > this email in error, please notify BroadSoft, Inc. immediately by > replying to this message, and destroy all copies of this message, > along with any attachment, prior to reading, distributing or copying it. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore____ > > __ __ > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Oct 1 13:24:22 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F417D11E8227 for ; Tue, 1 Oct 2013 13:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.334 X-Spam-Level: X-Spam-Status: No, score=-98.334 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptZQNom6vEip for ; Tue, 1 Oct 2013 13:24:08 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1920911E81B9 for ; Tue, 1 Oct 2013 13:24:06 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id gh4so5516674qeb.30 for ; Tue, 01 Oct 2013 13:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pRvv0+MAmODVoj6glMB31W7jheC/cuRTapCnk2XdCrw=; b=QuvsStX8VznUDMPaiRzQk3nUWQESBaZTOwrK1YuikOFMetOosyJc6INmFbBFM1ACrb 3Qvq1PploLo8fIEbaBOmUW7Sy/7ub3Y9/Qd0GiEspbSWhWgviFExVA+FbTMQ5rYQfTZx kDyEggNt4xJ33RMvndJpU6q7g+HHVCr4EGSuczPWVdNqKeH+Rl9X+tu9W5xO50chwJlj NZEqgeV0pwYyTpyEAmUsjNhs36rUMDYJCrGTKAnGrP/8CzEfLKmJ1eYY+4eGsuzoYDb7 IXz+nPONYfsqH8AQCePjLjT582+V2Qbov1LHWan9dGmQc6wpZxmpjvjwP9cBjIipD775 XlwA== MIME-Version: 1.0 X-Received: by 10.229.127.74 with SMTP id f10mr38109687qcs.16.1380659040067; Tue, 01 Oct 2013 13:24:00 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 1 Oct 2013 13:23:59 -0700 (PDT) In-Reply-To: <524B2832.9040201@alum.mit.edu> References: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> <576A8B541C219D4E9CEB1DF8C19C7B881A061FED@MBX08.citservers.local> <524B2832.9040201@alum.mit.edu> Date: Tue, 1 Oct 2013 15:23:59 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1133dd4ca3b75c04e7b3bbf3 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 20:24:23 -0000 --001a1133dd4ca3b75c04e7b3bbf3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 1, 2013 at 2:53 PM, Paul Kyzivat wrote: > IIUC, the change was to permit addr-spec as well as name-addr. > And this issue is then that a 4244 implementation won't be able to parse > that. Right? > [MB] It's possible that some folks might be able to parse it, but we shouldn't count on that.[/MB] > > Please ensure that the use cases are still correct after the change. > [MB] I don't think there's an issue with the call flows. [/MB] > > Thanks, > Paul > > > On 10/1/13 2:38 PM, Mary Barnes wrote: > >> Yes, you are correct - I misread the diffs and we did make the change >> based on Dale's comment, but we (authors) agree that it should be >> consistent with RFC 4244. >> >> Mary. >> >> >> On Tue, Oct 1, 2013 at 1:26 PM, Brett Tate > > wrote: >> >> Hi Mary,____ >> >> __ __ >> >> >> It looks like Dale requested the change; however, I think that it >> will cause interoperability issues with rfc4244 devices if an >> rfc4244bis devices sends an addr-spec. Thus I think that the change >> should be reverted (to be hi-targeted-to-uri= name-addr).____ >> >> __ __ >> >> http://www.ietf.org/mail-**archive/web/sipcore/current/** >> msg04158.html____ >> >> __ __ >> >> Thanks,____ >> >> Brett____ >> >> __ __ >> >> *From:*Mary Barnes [mailto:mary.ietf.barnes@**gmail.com >> >] >> *Sent:* Tuesday, October 01, 2013 1:41 PM >> >> >> *To:* Brett Tate >> *Cc:* draft-ietf-sipcore-rfc4244bis@**tools.ietf.org >> >> >; >> sipcore@ietf.org >> *Subject:* Re: [sipcore] draft-ietf-sipcore-rfc4244bis-**11: ABNF >> backward compatibility____ >> >> __ __ >> >> >> I don't think it was intentional. I backtracked and for whatever >> reason that change appeared in the individual -00 and I could find >> no email threads as to why we would have made that change. It >> appears Dale pointed out that issue a long time back, as well, but >> it seems we didn't make that fix. ____ >> >> __ __ >> >> >> So, that is an error and we should fix that. We have a couple other >> editorial/clarification points that Dale has pointed out that we >> will also include in a revision shortly.____ >> >> __ __ >> >> Thanks,____ >> >> Mary. ____ >> >> __ __ >> >> >> On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate > > wrote:____ >> >> >> Hi, >> >> The ABNF of draft-ietf-sipcore-rfc4244bis-**11's hi-targeted-to-uri >> is >> not backwards compatible with RFC 4244. >> >> Is this intentional? And if so, should it be mentioned within >> section 16 and/or 16.1? >> >> Thanks, >> Brett >> >> ----- >> >> draft-ietf-sipcore-rfc4244bis-**11: >> >> History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) >> >> hi-entry = hi-targeted-to-uri *(SEMI hi-param) >> >> hi-targeted-to-uri = addr-spec / name-addr >> >> >> RFC 4244: >> >> History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) >> >> hi-entry = hi-targeted-to-uri *( SEMI hi-param ) >> >> hi-targeted-to-uri= name-addr >> >> This email is intended solely for the person or entity to which it >> is addressed and may contain confidential and/or privileged >> information. If you are not the intended recipient and have received >> this email in error, please notify BroadSoft, Inc. immediately by >> replying to this message, and destroy all copies of this message, >> along with any attachment, prior to reading, distributing or copying >> it. >> ______________________________**_________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/**listinfo/sipcore____ >> >> __ __ >> >> >> >> >> >> ______________________________**_________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/**listinfo/sipcore >> >> > ______________________________**_________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/**listinfo/sipcore > --001a1133dd4ca3b75c04e7b3bbf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 1, 2013 at 2:53 PM,= Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
IIUC, the change was to permit addr-spec as = well as name-addr.
And this issue is then that a 4244 implementation won't be able to pars= e that. Right?
[MB] It's possible that some folks = might be able to parse it, but we shouldn't count on that.[/MB]=A0

Please ensure that the use cases are still correct after the change.
[MB] I don't think there's an issue with the call fl= ows. [/MB]=A0

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


On 10/1/13 2:38 PM, Mary Barnes wrote:
Yes, you are correct - I misread the diffs and we did make the change
based on Dale's comment, but we (authors) agree that it should be
consistent with RFC 4244.

Mary.


On Tue, Oct 1, 2013 at 1:26 PM, Brett Tate <brett@broadsoft.com
<mailto:brett@b= roadsoft.com>> wrote:

=A0 =A0 Hi Mary,____

=A0 =A0 __ __


=A0 =A0 It looks like Dale requested the change; however, I think that it =A0 =A0 will cause interoperability issues with rfc4244 devices if an
=A0 =A0 rfc4244bis devices sends an addr-spec. =A0Thus I think that the cha= nge
=A0 =A0 should be reverted (to be hi-targeted-to-uri=3D name-addr).____

=A0 =A0 __ __

=A0 =A0 http://www.ietf.org/mail-archive/web/s= ipcore/current/msg04158.html ____

=A0 =A0 __ __

=A0 =A0 Thanks,____

=A0 =A0 Brett____

=A0 =A0 __ __

=A0 =A0 *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com
=A0 =A0 <mailto:mary.ietf.barnes@gmail.com>]
=A0 =A0 *Sent:* Tuesday, October 01, 2013 1:41 PM


=A0 =A0 *To:* Brett Tate
=A0 =A0 *Cc:* draft-ietf-sipcore-rfc4244bis@tools.ietf.org
=A0 =A0 <mailto:draft-ietf-sipcore-rfc4244bis@tools.ietf.o= rg>;
=A0 =A0 sipcore@ietf.= org <mailto:si= pcore@ietf.org>
=A0 =A0 *Subject:* Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: A= BNF
=A0 =A0 backward compatibility____

=A0 =A0 __ __


=A0 =A0 I don't think it was intentional. =A0I backtracked and for what= ever
=A0 =A0 reason that change appeared in the individual -00 and I could find<= br> =A0 =A0 no email threads as to why we would have made that change. =A0 It =A0 =A0 appears Dale pointed out that issue a long time back, as well, but<= br>
=A0 =A0 it seems we didn't make that fix. ____

=A0 =A0 __ __


=A0 =A0 So, that is an error and we should fix that. =A0We have a couple ot= her
=A0 =A0 editorial/clarification points that Dale has pointed out that we
=A0 =A0 will also include in a revision shortly.____

=A0 =A0 __ __

=A0 =A0 Thanks,____

=A0 =A0 Mary. ____

=A0 =A0 __ __


=A0 =A0 On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate <brett@broadsoft.com
=A0 =A0 <mailto:brett@broadsoft.com>> wrote:____


=A0 =A0 Hi,

=A0 =A0 The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-target= ed-to-uri is
=A0 =A0 not backwards compatible with RFC 4244.

=A0 =A0 Is this intentional? =A0And if so, should it be mentioned within =A0 =A0 section 16 and/or 16.1?

=A0 =A0 Thanks,
=A0 =A0 Brett

=A0 =A0 -----

=A0 =A0 draft-ietf-sipcore-rfc4244bis-11:

=A0 =A0 =A0 =A0History-Info =3D "History-Info" HCOLON hi-entry *(= COMMA hi-entry)

=A0 =A0 =A0 =A0hi-entry =3D hi-targeted-to-uri *(SEMI hi-param)

=A0 =A0 =A0 =A0hi-targeted-to-uri =3D addr-spec / name-addr


=A0 =A0 RFC 4244:

=A0 =A0 =A0 =A0History-Info =3D "History-Info" HCOLON hi-entry *(= COMMA hi-entry)

=A0 =A0 =A0 =A0hi-entry =3D hi-targeted-to-uri *( SEMI hi-param )

=A0 =A0 =A0 =A0hi-targeted-to-uri=3D name-addr

=A0 =A0 This email is intended solely for the person or entity to which it<= br> =A0 =A0 is addressed and may contain confidential and/or privileged
=A0 =A0 information. If you are not the intended recipient and have receive= d
=A0 =A0 this email in error, please notify BroadSoft, Inc. immediately by =A0 =A0 replying to this message, and destroy all copies of this message, =A0 =A0 along with any attachment, prior to reading, distributing or copyin= g it.
=A0 =A0 _______________________________________________
=A0 =A0 sipcore mailing list
=A0 =A0 sipcore@ietf.= org <mailto:si= pcore@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/listinfo/sipcore____
=A0 =A0 __ __





_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--001a1133dd4ca3b75c04e7b3bbf3-- From pkyzivat@alum.mit.edu Tue Oct 1 13:52:48 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E63211E8211 for ; Tue, 1 Oct 2013 13:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.162 X-Spam-Level: ** X-Spam-Status: No, score=2.162 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x387gycz7jdC for ; Tue, 1 Oct 2013 13:52:37 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 2C74911E8153 for ; Tue, 1 Oct 2013 13:52:36 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Xsxl1m0071ZXKqc5BwsbCc; Tue, 01 Oct 2013 20:52:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id Xwsb1m00J3ZTu2S3hwsbsv; Tue, 01 Oct 2013 20:52:35 +0000 Message-ID: <524B3612.7070903@alum.mit.edu> Date: Tue, 01 Oct 2013 16:52:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mary Barnes References: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> <576A8B541C219D4E9CEB1DF8C19C7B881A061FED@MBX08.citservers.local> <524B2832.9040201@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380660755; bh=Cjv3WISad9zGCZT6AK0ejno4XKY5LQ7++5pTjAA4nKc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Gz6TYDURCNhl8G2sFz/oI13N1lIl1dfNUnInI9vsiv9WBcwkkj4qvAsNew9C5X2Wx l8ReagYxnuwCD4oZFEI/G/SkEVF0YLEvIDf0WIQ+4IX4v5qaSa/Vd72I8HCcREdX77 TAfXUVt+DTJdmMbA6MuJ5tEXXsK2REnC0hiET8I0aR4vWFL1uE7BfWAMdeWzYUqiGC 755597Ij3WnEZS0L3JVjh7UpEymZzUPrQhgO2igABNrLIxD9TM8GV2MZP6wZ67tVdC alUL1/Utdw2m0zeg73m7qYcNTBlsyaoGKZpzK19ckPjWTuxG+DbVn2+0T1bNfWGzqr Hzo6LfTDkdryA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 20:52:48 -0000 On 10/1/13 4:23 PM, Mary Barnes wrote: > On Tue, Oct 1, 2013 at 2:53 PM, Paul Kyzivat > wrote: > > IIUC, the change was to permit addr-spec as well as name-addr. > And this issue is then that a 4244 implementation won't be able to > parse that. Right? > > [MB] It's possible that some folks might be able to parse it, but we > shouldn't count on that.[/MB] No. > Please ensure that the use cases are still correct after the change. > > [MB] I don't think there's an issue with the call flows. [/MB] I just looked, and I think you are right. > Thanks, > Paul > > > On 10/1/13 2:38 PM, Mary Barnes wrote: > > Yes, you are correct - I misread the diffs and we did make the > change > based on Dale's comment, but we (authors) agree that it should be > consistent with RFC 4244. > > Mary. > > > On Tue, Oct 1, 2013 at 1:26 PM, Brett Tate > >> wrote: > > Hi Mary,____ > > __ __ > > > It looks like Dale requested the change; however, I think > that it > will cause interoperability issues with rfc4244 devices if an > rfc4244bis devices sends an addr-spec. Thus I think that > the change > should be reverted (to be hi-targeted-to-uri= name-addr).____ > > __ __ > > http://www.ietf.org/mail-__archive/web/sipcore/current/__msg04158.html > > ____ > > __ __ > > Thanks,____ > > Brett____ > > __ __ > > *From:*Mary Barnes [mailto:mary.ietf.barnes@__gmail.com > > >] > *Sent:* Tuesday, October 01, 2013 1:41 PM > > > *To:* Brett Tate > *Cc:* draft-ietf-sipcore-rfc4244bis@__tools.ietf.org > > >; > sipcore@ietf.org > > > *Subject:* Re: [sipcore] > draft-ietf-sipcore-rfc4244bis-__11: ABNF > backward compatibility____ > > __ __ > > > I don't think it was intentional. I backtracked and for > whatever > reason that change appeared in the individual -00 and I > could find > no email threads as to why we would have made that change. It > appears Dale pointed out that issue a long time back, as > well, but > it seems we didn't make that fix. ____ > > __ __ > > > So, that is an error and we should fix that. We have a > couple other > editorial/clarification points that Dale has pointed out > that we > will also include in a revision shortly.____ > > __ __ > > Thanks,____ > > Mary. ____ > > __ __ > > > On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate > > >> > wrote:____ > > > Hi, > > The ABNF of draft-ietf-sipcore-rfc4244bis-__11's > hi-targeted-to-uri is > not backwards compatible with RFC 4244. > > Is this intentional? And if so, should it be mentioned within > section 16 and/or 16.1? > > Thanks, > Brett > > ----- > > draft-ietf-sipcore-rfc4244bis-__11: > > History-Info = "History-Info" HCOLON hi-entry *(COMMA > hi-entry) > > hi-entry = hi-targeted-to-uri *(SEMI hi-param) > > hi-targeted-to-uri = addr-spec / name-addr > > > RFC 4244: > > History-Info = "History-Info" HCOLON hi-entry *(COMMA > hi-entry) > > hi-entry = hi-targeted-to-uri *( SEMI hi-param ) > > hi-targeted-to-uri= name-addr > > This email is intended solely for the person or entity to > which it > is addressed and may contain confidential and/or privileged > information. If you are not the intended recipient and have > received > this email in error, please notify BroadSoft, Inc. > immediately by > replying to this message, and destroy all copies of this > message, > along with any attachment, prior to reading, distributing > or copying it. > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > > > https://www.ietf.org/mailman/__listinfo/sipcore____ > > > __ __ > > > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > From shida@agnada.com Tue Oct 1 15:57:04 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB07421E8254 for ; Tue, 1 Oct 2013 15:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGN1H8pN23VB for ; Tue, 1 Oct 2013 15:56:42 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.56.148.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8323621E810A for ; Tue, 1 Oct 2013 15:56:39 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id DB6828151750B; Tue, 1 Oct 2013 17:56:38 -0500 (CDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) by gateway05.websitewelcome.com (Postfix) with ESMTP id CB2F7815174E7 for ; Tue, 1 Oct 2013 17:56:38 -0500 (CDT) Received: from [208.66.25.2] (port=61022 helo=[192.168.1.11]) by gator4135.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VR8ru-0005jF-1n; Tue, 01 Oct 2013 17:56:38 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_26B3CFB3-E708-4064-823F-45E92B64A629" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Shida Schubert In-Reply-To: Date: Tue, 1 Oct 2013 15:56:37 -0700 Message-Id: <13DABB8F-53F3-43D6-9012-E7E0BA88462F@agnada.com> References: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> <576A8B541C219D4E9CEB1DF8C19C7B881A061FED@MBX08.citservers.local> <524B2832.9040201@alum.mit.edu> To: Mary Barnes X-Mailer: Apple Mail (2.1510) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - agnada.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.11]) [208.66.25.2]:61022 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 22:57:04 -0000 --Apple-Mail=_26B3CFB3-E708-4064-823F-45E92B64A629 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 1, 2013, at 1:23 PM, Mary Barnes = wrote: > On Tue, Oct 1, 2013 at 2:53 PM, Paul Kyzivat = wrote: > IIUC, the change was to permit addr-spec as well as name-addr. > And this issue is then that a 4244 implementation won't be able to = parse that. Right? > [MB] It's possible that some folks might be able to parse it, but we = shouldn't count on that.[/MB]=20 >=20 > Please ensure that the use cases are still correct after the change. > [MB] I don't think there's an issue with the call flows. [/MB]=20 I can confirm this.=20 Shida >=20 > Thanks, > Paul >=20 >=20 > On 10/1/13 2:38 PM, Mary Barnes wrote: > Yes, you are correct - I misread the diffs and we did make the change > based on Dale's comment, but we (authors) agree that it should be > consistent with RFC 4244. >=20 > Mary. >=20 >=20 > On Tue, Oct 1, 2013 at 1:26 PM, Brett Tate > wrote: >=20 > Hi Mary,____ >=20 > __ __ >=20 >=20 > It looks like Dale requested the change; however, I think that it > will cause interoperability issues with rfc4244 devices if an > rfc4244bis devices sends an addr-spec. Thus I think that the = change > should be reverted (to be hi-targeted-to-uri=3D name-addr).____ >=20 > __ __ >=20 > http://www.ietf.org/mail-archive/web/sipcore/current/msg04158.html = ____ >=20 > __ __ >=20 > Thanks,____ >=20 > Brett____ >=20 > __ __ >=20 > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com > ] > *Sent:* Tuesday, October 01, 2013 1:41 PM >=20 >=20 > *To:* Brett Tate > *Cc:* draft-ietf-sipcore-rfc4244bis@tools.ietf.org > ; > sipcore@ietf.org > *Subject:* Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF > backward compatibility____ >=20 > __ __ >=20 >=20 > I don't think it was intentional. I backtracked and for whatever > reason that change appeared in the individual -00 and I could find > no email threads as to why we would have made that change. It > appears Dale pointed out that issue a long time back, as well, but > it seems we didn't make that fix. ____ >=20 > __ __ >=20 >=20 > So, that is an error and we should fix that. We have a couple = other > editorial/clarification points that Dale has pointed out that we > will also include in a revision shortly.____ >=20 > __ __ >=20 > Thanks,____ >=20 > Mary. ____ >=20 > __ __ >=20 >=20 > On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate > wrote:____ >=20 >=20 > Hi, >=20 > The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-targeted-to-uri = is > not backwards compatible with RFC 4244. >=20 > Is this intentional? And if so, should it be mentioned within > section 16 and/or 16.1? >=20 > Thanks, > Brett >=20 > ----- >=20 > draft-ietf-sipcore-rfc4244bis-11: >=20 > History-Info =3D "History-Info" HCOLON hi-entry *(COMMA = hi-entry) >=20 > hi-entry =3D hi-targeted-to-uri *(SEMI hi-param) >=20 > hi-targeted-to-uri =3D addr-spec / name-addr >=20 >=20 > RFC 4244: >=20 > History-Info =3D "History-Info" HCOLON hi-entry *(COMMA = hi-entry) >=20 > hi-entry =3D hi-targeted-to-uri *( SEMI hi-param ) >=20 > hi-targeted-to-uri=3D name-addr >=20 > This email is intended solely for the person or entity to which it > is addressed and may contain confidential and/or privileged > information. If you are not the intended recipient and have = received > this email in error, please notify BroadSoft, Inc. immediately by > replying to this message, and destroy all copies of this message, > along with any attachment, prior to reading, distributing or = copying it. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore____ >=20 > __ __ >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_26B3CFB3-E708-4064-823F-45E92B64A629 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Oct 1, 2013, at 1:23 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

On Tue, Oct 1, 2013 at 2:53 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
IIUC, the change was to permit addr-spec as well as name-addr.
And this issue is then that a 4244 implementation won't be able to parse that. Right?
[MB] It's possible that some folks might be able to parse it, but we shouldn't count on that.[/MB] 

Please ensure that the use cases are still correct after the change.
[MB] I don't think there's an issue with the call flows. [/MB] 

 I can confirm this. 

 Shida


        Thanks,
        Paul


On 10/1/13 2:38 PM, Mary Barnes wrote:
Yes, you are correct - I misread the diffs and we did make the change
based on Dale's comment, but we (authors) agree that it should be
consistent with RFC 4244.

Mary.


On Tue, Oct 1, 2013 at 1:26 PM, Brett Tate <brett@broadsoft.com
<mailto:brett@broadsoft.com>> wrote:

    Hi Mary,____

    __ __


    It looks like Dale requested the change; however, I think that it
    will cause interoperability issues with rfc4244 devices if an
    rfc4244bis devices sends an addr-spec.  Thus I think that the change
    should be reverted (to be hi-targeted-to-uri= name-addr).____

    __ __

    http://www.ietf.org/mail-archive/web/sipcore/current/msg04158.html ____

    __ __

    Thanks,____

    Brett____

    __ __

    *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com
    <mailto:mary.ietf.barnes@gmail.com>]
    *Sent:* Tuesday, October 01, 2013 1:41 PM


    *To:* Brett Tate
    *Cc:* draft-ietf-sipcore-rfc4244bis@tools.ietf.org
    <mailto:draft-ietf-sipcore-rfc4244bis@tools.ietf.org>;
    sipcore@ietf.org <mailto:sipcore@ietf.org>
    *Subject:* Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF
    backward compatibility____

    __ __


    I don't think it was intentional.  I backtracked and for whatever
    reason that change appeared in the individual -00 and I could find
    no email threads as to why we would have made that change.   It
    appears Dale pointed out that issue a long time back, as well, but
    it seems we didn't make that fix. ____

    __ __


    So, that is an error and we should fix that.  We have a couple other
    editorial/clarification points that Dale has pointed out that we
    will also include in a revision shortly.____

    __ __

    Thanks,____

    Mary. ____

    __ __


    On Tue, Oct 1, 2013 at 9:46 AM, Brett Tate <brett@broadsoft.com
    <mailto:brett@broadsoft.com>> wrote:____


    Hi,

    The ABNF of draft-ietf-sipcore-rfc4244bis-11's hi-targeted-to-uri is
    not backwards compatible with RFC 4244.

    Is this intentional?  And if so, should it be mentioned within
    section 16 and/or 16.1?

    Thanks,
    Brett

    -----

    draft-ietf-sipcore-rfc4244bis-11:

       History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)

       hi-entry = hi-targeted-to-uri *(SEMI hi-param)

       hi-targeted-to-uri = addr-spec / name-addr


    RFC 4244:

       History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry)

       hi-entry = hi-targeted-to-uri *( SEMI hi-param )

       hi-targeted-to-uri= name-addr

    This email is intended solely for the person or entity to which it
    is addressed and may contain confidential and/or privileged
    information. If you are not the intended recipient and have received
    this email in error, please notify BroadSoft, Inc. immediately by
    replying to this message, and destroy all copies of this message,
    along with any attachment, prior to reading, distributing or copying it.
    _______________________________________________
    sipcore mailing list
    sipcore@ietf.org <mailto:sipcore@ietf.org>
    https://www.ietf.org/mailman/listinfo/sipcore____

    __ __





_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--Apple-Mail=_26B3CFB3-E708-4064-823F-45E92B64A629-- From worley@shell01.TheWorld.com Wed Oct 2 12:33:46 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4DB11E80D3 for ; Wed, 2 Oct 2013 12:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUAbBUHFpqyD for ; Wed, 2 Oct 2013 12:33:34 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id B707C21F90E5 for ; Wed, 2 Oct 2013 12:21:21 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r92JKqpR027932; Wed, 2 Oct 2013 15:20:54 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r92JKp3e2240644; Wed, 2 Oct 2013 15:20:51 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r92JKkvX2240019; Wed, 2 Oct 2013 15:20:46 -0400 (EDT) Date: Wed, 2 Oct 2013 15:20:46 -0400 (EDT) Message-Id: <201310021920.r92JKkvX2240019@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Mary Barnes In-reply-to: (mary.ietf.barnes@gmail.com) References: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> <576A8B541C219D4E9CEB1DF8C19C7B881A061FED@MBX08.citservers.local> <524B2832.9040201@alum.mit.edu> Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 19:33:46 -0000 > From: Mary Barnes > > On Tue, Oct 1, 2013 at 2:53 PM, Paul Kyzivat wrote: > > > IIUC, the change was to permit addr-spec as well as name-addr. > > And this issue is then that a 4244 implementation won't be able to parse > > that. Right? > > > [MB] It's possible that some folks might be able to parse it, but we > shouldn't count on that.[/MB] It's unfortunate, because essentially everywhere else where a header has this general syntax, either a name-addr or an addr-spec is allowed. But for upward compatibility, we're stuck with what 4244 allowed. > > Please ensure that the use cases are still correct after the change. > > > [MB] I don't think there's an issue with the call flows. [/MB] I searched both drafts, and all hi-entries use name-addrs. Dale From oferg@avaya.com Thu Oct 3 01:18:42 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB3821F967F for ; Thu, 3 Oct 2013 01:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sV3k9U53AjYi for ; Thu, 3 Oct 2013 01:18:24 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D5E7821F949F for ; Thu, 3 Oct 2013 01:16:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFANsmTVLGmAcV/2dsb2JhbABagkMjIThSwTiBHxZtB4InAQEDEhteARUVViYBBBsah2QBm22ER5x0jyCDV4EEA5QkijmLI4MkgWgEPg X-IronPort-AV: E=Sophos;i="4.90,1024,1371096000"; d="scan'208,217";a="26392474" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Oct 2013 04:16:01 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Oct 2013 04:12:28 -0400 Received: from AZ-FFEXMB01.global.avaya.com ([fe80::39ee:75fe:e67a:cf4a]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0146.000; Thu, 3 Oct 2013 04:16:00 -0400 From: "Goren, Ofer (Ofer)" To: "sipcore@ietf.org" Thread-Topic: RFC 3261, question on provisional timer Thread-Index: Ac7AEId/rJid4wbQT3OGGwF+WCGA3A== Date: Thu, 3 Oct 2013 08:16:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_E13E2A10A9E01C40B51180C484B57339031BB982AZFFEXMB01globa_" MIME-Version: 1.0 Subject: [sipcore] RFC 3261, question on provisional timer X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 08:18:42 -0000 --_000_E13E2A10A9E01C40B51180C484B57339031BB982AZFFEXMB01globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi. According to RFC 3261, section 13.3.1.1: If the UAS desires an extended period of time to answer the INVITE, it will need to ask for an "extension" in order to prevent proxies from canceling the transaction. A proxy has the option of canceling a transaction when there is a gap of 3 minutes between responses in a transaction. To prevent cancellation, the UAS MUST send a non-100 provisional response at every minute, to handle the possibility of lost provisional responses. Does this mean that UACs should also reset their timer when receiving seque= ntial provisional responses, or does this section only relevant to proxies? Thanks! Ofer --_000_E13E2A10A9E01C40B51180C484B57339031BB982AZFFEXMB01globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi.

 

According to RFC 3261, section 13.3.1.1:<= /p>

   If the UA= S desires an extended period of time to answer the INVITE,

   it will n= eed to ask for an "extension" in order to prevent proxies<= o:p>

   from canc= eling the transaction.  A proxy has the option of canceling

   a transac= tion when there is a gap of 3 minutes between responses in a

   transacti= on.  To prevent cancellation, the UAS MUST send a non-100<= /o:p>

   provision= al response at every minute, to handle the possibility of=

   lost prov= isional responses.

 

Does this mean that UACs should also reset their tim= er when receiving sequential provisional responses, or does this section on= ly relevant to proxies?

 

Thanks!

 

Ofer

 

--_000_E13E2A10A9E01C40B51180C484B57339031BB982AZFFEXMB01globa_-- From andrew.hutton@siemens-enterprise.com Thu Oct 3 02:10:34 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D632121F963F for ; Thu, 3 Oct 2013 02:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4abn-b1OMzt for ; Thu, 3 Oct 2013 02:10:24 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 928A721F9D70 for ; Thu, 3 Oct 2013 02:09:52 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id C728F23F04FC; Thu, 3 Oct 2013 11:09:48 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.31]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Thu, 3 Oct 2013 11:09:21 +0200 From: "Hutton, Andrew" To: "Olle E. Johansson" , "sipcore@ietf.org WG" Thread-Topic: [sipcore] Locating SIP servers in a dual stack IP network Thread-Index: AQHOveUljxu59luB2kGWuPJTjqMmHJnis94g Date: Thu, 3 Oct 2013 09:09:18 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BE2FC7@MCHP04MSX.global-ad.net> References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> In-Reply-To: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Gonzalo Salgueiro \(gsalguei\)" , Cullen Jennings Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 09:10:35 -0000 I believe SIPCore should adopt draft-johansson-sip-dual-stack and I am will= ing to contribute, review etc. Andy > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Olle E. Johansson > Sent: 30 September 2013 14:59 > To: sipcore@ietf.org WG > Cc: Olle E. Johansson; Gonzalo Salgueiro (gsalguei); Cullen Jennings > Subject: [sipcore] Locating SIP servers in a dual stack IP network >=20 > Hi! > We have written a draft that updates RFC 3263 to better handle dual > stack issues and prepare for another draft that clarifies Happy > Eyeballs-like procedures for setting up connections with SIP in dual > stack networks. >=20 > The document in the current version can be found here: > http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01 >=20 > This draft is a result of the work in the SIP forum IPv6 working group. > During SIPit events and discussions in the wg we've located a couple of > issues with RFC 3263 and the way we handle SRV results. During the IETF > meeting in Berlin I consulted with the IETF DNS directorate and they > confirmed that RFC 3263 doesn't follow the DNS SRV RFC in the way it > describes handling IPv6 and IPv4 - specially where it instructs > implementers to look up either address family, but not both. The DNS > SRV RFC clearly states that ALL addresses for a host name should be > used and connections should be tried before the next host name in the > list is used (higher priority). >=20 > We've discussed this with the chairs of dispatch (Cullen, Mary) and > they feel this is a document for the SIPcore working group. The chairs > of SIPcore agreed in meetings in Berlin. The charter clearly states > that SIPcore handles updates to core documents. >=20 > I guess the question now is if the SIPcore wg is willing to adopt this > work? >=20 >=20 > Best regards, > /Olle > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From brett@broadsoft.com Thu Oct 3 04:20:13 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A18721E8064 for ; Thu, 3 Oct 2013 04:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrBPwn1Bk90p for ; Thu, 3 Oct 2013 04:19:54 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id C413D21F9E6D for ; Thu, 3 Oct 2013 04:15:28 -0700 (PDT) Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 3 Oct 2013 04:16:28 -0700 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Thu, 3 Oct 2013 04:16:28 -0700 From: Brett Tate To: "Goren, Ofer (Ofer)" , "sipcore@ietf.org" Thread-Topic: RFC 3261, question on provisional timer Thread-Index: Ac7AEId/rJid4wbQT3OGGwF+WCGA3AAE9oBg Date: Thu, 3 Oct 2013 11:16:27 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A062380@MBX08.citservers.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] RFC 3261, question on provisional timer X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 11:20:13 -0000 > Does this mean that UACs should also reset their timer=20 > when receiving sequential provisional responses, or=20 > does this section only relevant to proxies? As shown within appendix A table 4, Timer C has been defined as a proxy INV= ITE transaction timer. The UAC has other mechanisms to determine if a dialog is still active. For= instance, it can send UPDATE. However, some vendors may choose to use Tim= er C since the alternative mechanisms are not always possible (e.g. UPDATE = support is not mandatory). Within the following link, Jonathan indicates t= hat the UAs do whatever they want. http://bugs.sipit.net/show_bug.cgi?id=3D706=20 If you are not aware of it, you may interested in the following mailing lis= t: https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Thanks, Brett From oferg@avaya.com Thu Oct 3 05:01:20 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B0321E804D for ; Thu, 3 Oct 2013 05:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7Mpry2zb68p for ; Thu, 3 Oct 2013 05:01:03 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED5721F84F8 for ; Thu, 3 Oct 2013 04:53:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAHxZTVLGmAcV/2dsb2JhbABZgmYhOFLBO4EgFnSCJQEBAQECAQEBAQ8oNBAHBAIBCA0EBAEBCxQJBycBChQJCAEBBAESCBqHXgYBC59ynF0XjyA4BoMZgQQDlTaDeoUtiyODJIIq X-IronPort-AV: E=Sophos;i="4.90,1025,1371096000"; d="scan'208";a="26409893" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Oct 2013 07:53:48 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Oct 2013 07:50:07 -0400 Received: from AZ-FFEXMB01.global.avaya.com ([fe80::39ee:75fe:e67a:cf4a]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Thu, 3 Oct 2013 13:53:38 +0200 From: "Goren, Ofer (Ofer)" To: Brett Tate , "sipcore@ietf.org" Thread-Topic: RFC 3261, question on provisional timer Thread-Index: Ac7AEId/rJid4wbQT3OGGwF+WCGA3AAE9oBgAAKnIvA= Date: Thu, 3 Oct 2013 11:53:38 +0000 Message-ID: References: <576A8B541C219D4E9CEB1DF8C19C7B881A062380@MBX08.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A062380@MBX08.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] RFC 3261, question on provisional timer X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 12:01:20 -0000 Hi Brett. Thank you for the answer. It means that as a UAC, I can use timer C to "all= ow" the UAS extending the timer on its side, but this was not the original = intension of the authors. Correct? Ofer -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com]=20 Sent: Thursday, October 03, 2013 2:16 PM To: Goren, Ofer (Ofer); sipcore@ietf.org Subject: RE: RFC 3261, question on provisional timer > Does this mean that UACs should also reset their timer when receiving=20 > sequential provisional responses, or does this section only relevant=20 > to proxies? As shown within appendix A table 4, Timer C has been defined as a proxy INV= ITE transaction timer. The UAC has other mechanisms to determine if a dialog is still active. For= instance, it can send UPDATE. However, some vendors may choose to use Tim= er C since the alternative mechanisms are not always possible (e.g. UPDATE = support is not mandatory). Within the following link, Jonathan indicates t= hat the UAs do whatever they want. http://bugs.sipit.net/show_bug.cgi?id=3D706=20 If you are not aware of it, you may interested in the following mailing lis= t: https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Thanks, Brett From brett@broadsoft.com Thu Oct 3 05:11:34 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF8B21E804D for ; Thu, 3 Oct 2013 05:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pwrsAQFM7do for ; Thu, 3 Oct 2013 05:11:24 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 1656E21F8616 for ; Thu, 3 Oct 2013 05:05:40 -0700 (PDT) Received: from CASUMHUB04.citservers.local (172.16.98.225) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 3 Oct 2013 05:06:40 -0700 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Thu, 3 Oct 2013 05:06:40 -0700 From: Brett Tate To: "Goren, Ofer (Ofer)" , "sipcore@ietf.org" Thread-Topic: RFC 3261, question on provisional timer Thread-Index: Ac7AEId/rJid4wbQT3OGGwF+WCGA3AAE9oBgAAKnIvAAACVT0A== Date: Thu, 3 Oct 2013 12:06:40 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06239E@MBX08.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B881A062380@MBX08.citservers.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] RFC 3261, question on provisional timer X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 12:11:34 -0000 > It means that as a UAC, I can use timer C to "allow" the=20 > UAS extending the timer on its side, but this was not the > original intension of the authors. > Correct? Yes. However, a UAC can typically use a better mechanism such as UPDATE. = Timer C was introduced by RFC 3261. Thus a UAC relying just upon Timer C w= ould have interoperability issues with RFC 2543 devices. > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Thursday, October 03, 2013 2:16 PM > To: Goren, Ofer (Ofer); sipcore@ietf.org > Subject: RE: RFC 3261, question on provisional timer >=20 > > Does this mean that UACs should also reset their timer when receiving > > sequential provisional responses, or does this section only relevant > > to proxies? >=20 > As shown within appendix A table 4, Timer C has been defined as a proxy > INVITE transaction timer. >=20 > The UAC has other mechanisms to determine if a dialog is still active. > For instance, it can send UPDATE. However, some vendors may choose to > use Timer C since the alternative mechanisms are not always possible > (e.g. UPDATE support is not mandatory). Within the following link, > Jonathan indicates that the UAs do whatever they want. >=20 > http://bugs.sipit.net/show_bug.cgi?id=3D706 >=20 >=20 > If you are not aware of it, you may interested in the following mailing > list: >=20 > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >=20 > Thanks, > Brett From worley@shell01.TheWorld.com Thu Oct 3 12:06:18 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A2421F9C78 for ; Thu, 3 Oct 2013 12:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKCVhYR7YrOW for ; Thu, 3 Oct 2013 12:06:06 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 1605D21E80D5 for ; Thu, 3 Oct 2013 11:56:02 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r93ItquC008816; Thu, 3 Oct 2013 14:55:54 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r93ItpGx2300850; Thu, 3 Oct 2013 14:55:51 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r93Itknq2299577; Thu, 3 Oct 2013 14:55:46 -0400 (EDT) Date: Thu, 3 Oct 2013 14:55:46 -0400 (EDT) Message-Id: <201310031855.r93Itknq2299577@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-reply-to: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> (oej@edvina.net) References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> Cc: sipcore@ietf.org Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:06:18 -0000 > From: "Olle E. Johansson" > > We have written a draft that updates RFC 3263 to better handle dual > stack issues and prepare for another draft that clarifies Happy > Eyeballs-like procedures for setting up connections with SIP in dual > stack networks. > > The document in the current version can be found here: > http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01 > I guess the question now is if the SIPcore wg is willing to adopt > this work? It is clear that we need to clean up any problems that SIP has in dual-stack environments now that IPv6 usage is starting to increase. So Sipcore should accept this work item. Dale From rifaat.ietf@gmail.com Thu Oct 3 17:17:54 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9025321E808A for ; Thu, 3 Oct 2013 17:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sax81SZoRE7y for ; Thu, 3 Oct 2013 17:17:47 -0700 (PDT) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id F3B7021F8D20 for ; Thu, 3 Oct 2013 17:17:46 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id i11so2370638qej.39 for ; Thu, 03 Oct 2013 17:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fxPZXIMRNakUbFyp1eRdQo38bU+DS9AoWyuTwctGuDE=; b=jXlKvdgi2WRgrx8AhnKLwQwf7+PHP3txCSJH4GCgX0p8C7eBGESrrhxuDib3BXyhrg d3npbqncV5iFc9zvQU9Em7JBcSZQEIYYlYs/3Mwtt5StPDp7LrOA+PGV1oyVZ6y7sMdb PHMjPcFJ59Hw9t4sOQ+sXMz0m2XSVI7uk0MJO02l9bgLewvYDIVzFfzjvLTXXuBQjxPl Fq1h9++pS0Ap/712YXR5m1XuW+R3nwfepcmDW3G0gPggLDAM3wy/+eg/NR8MCXWNoqjh op443R+n5LMOie/7lu7LyrRJXFUzfTNNtPy2GoDRT/pKvyRCVZV40Dah6eRKP8ojk6Nt lHvA== MIME-Version: 1.0 X-Received: by 10.224.111.196 with SMTP id t4mr14030870qap.89.1380845866064; Thu, 03 Oct 2013 17:17:46 -0700 (PDT) Received: by 10.49.16.105 with HTTP; Thu, 3 Oct 2013 17:17:45 -0700 (PDT) In-Reply-To: <201310031855.r93Itknq2299577@shell01.TheWorld.com> References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> Date: Thu, 3 Oct 2013 20:17:45 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a11c2d60056216104e7df3b92 Cc: sipcore@ietf.org, "Olle E. Johansson" Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 00:17:54 -0000 --001a11c2d60056216104e7df3b92 Content-Type: text/plain; charset=ISO-8859-1 I too think that we need to clarify the dual-stack environment in SIP and support this work item in the SIP Core. Regards, Rifaat On Thu, Oct 3, 2013 at 2:55 PM, Dale R. Worley wrote: > > From: "Olle E. Johansson" > > > > We have written a draft that updates RFC 3263 to better handle dual > > stack issues and prepare for another draft that clarifies Happy > > Eyeballs-like procedures for setting up connections with SIP in dual > > stack networks. > > > > The document in the current version can be found here: > > http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01 > > > I guess the question now is if the SIPcore wg is willing to adopt > > this work? > > It is clear that we need to clean up any problems that SIP has in > dual-stack environments now that IPv6 usage is starting to increase. > So Sipcore should accept this work item. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a11c2d60056216104e7df3b92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I too think that we need to clarify the dual-stack environ= ment in SIP and support this work item in the SIP Core.

= Regards,
=A0Rifaat



On Thu, Oct 3, 2013 at 2:55 PM, Dale R. = Worley <worley@ariadne.com> wrote:
> From: "Olle E. Johansson" <oej@edvina.net>
>
> We have written a draft that updates RFC 3263 to better handle dual > stack issues and prepare for another draft that clarifies Happy
> Eyeballs-like procedures for setting up connections with SIP in dual > stack networks.
>
> The document in the current version can be found here:
> http://tools.ietf.org/html/draft-johansson-sip-dual-st= ack-01

> I guess the question now is if the SIPcore wg = is willing to adopt
> this work?

It is clear that we need to clean up any problems that SIP has in
dual-stack environments now that IPv6 usage is starting to increase.
So Sipcore should accept this work item.

Dale
_____________________= __________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--001a11c2d60056216104e7df3b92-- From dhanes@cisco.com Fri Oct 4 10:30:07 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CDA21F9CA6 for ; Fri, 4 Oct 2013 10:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgFEBP+3-SRo for ; Fri, 4 Oct 2013 10:30:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8AE21F9C12 for ; Fri, 4 Oct 2013 10:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6968; q=dns/txt; s=iport; t=1380907802; x=1382117402; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=rflRrJXhO7E/O8AMYjcGrVJk7kWbxrSAN+bsNF4BIwM=; b=eY7hnx98hqKL0hdtuxNJcLuukT8OPuteS6Or2DttZeV4rzOrcqAGam8y RftT14D/h9YBsJvKv4wIVqs6cZuUE2iS8b0Td3QekbltBWU2gwDbRz17L YtC72xY/yTZHD9bdk2sHHL9gmoSGGku5eBciGavY9HfE8z8RrBsywd3ni 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMFAK36TlKtJXHA/2dsb2JhbABZgkNEOFK5BYd5SoEaFnSCJQEBAQMBAQEBawsFDQEIEQMBAgEKHS4LFAkIAgQOBQiHeAYMvCaPICANBAYBgx+BBAOZMJBQgySCKg X-IronPort-AV: E=Sophos;i="4.90,1034,1371081600"; d="scan'208,217";a="268019090" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 04 Oct 2013 17:30:01 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r94HU0po027015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Oct 2013 17:30:00 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 4 Oct 2013 12:30:00 -0500 From: "David Hanes (dhanes)" To: "Dale R. Worley" Thread-Topic: [sipcore] Locating SIP servers in a dual stack IP network Thread-Index: AQHOveUv7oZT59pTfEykQa0II2UaOZnk46yA Date: Fri, 4 Oct 2013 17:30:00 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.117.39.199] Content-Type: multipart/alternative; boundary="_000_ACF1600D3C04D24BABD489DF98B82BB9470916BBxmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: "sipcore@ietf.org" , "Olle E. Johansson" Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 17:30:08 -0000 --_000_ACF1600D3C04D24BABD489DF98B82BB9470916BBxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Totally agree. This really needs to be addressed and SIPCORE seems the rig= ht place. -David Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network Date: October 3, 2013 8:17:45 PM EDT To: "Dale R. Worley" > Cc: >, "Olle E. Johansson" > I too think that we need to clarify the dual-stack environment in SIP and s= upport this work item in the SIP Core. Regards, Rifaat On Thu, Oct 3, 2013 at 2:55 PM, Dale R. Worley > wrote: > From: "Olle E. Johansson" > > > We have written a draft that updates RFC 3263 to better handle dual > stack issues and prepare for another draft that clarifies Happy > Eyeballs-like procedures for setting up connections with SIP in dual > stack networks. > > The document in the current version can be found here: > http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01 > I guess the question now is if the SIPcore wg is willing to adopt > this work? It is clear that we need to clean up any problems that SIP has in dual-stack environments now that IPv6 usage is starting to increase. So Sipcore should accept this work item. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_ACF1600D3C04D24BABD489DF98B82BB9470916BBxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <1DC8FF13B3017640B935F8B943EA38F6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Totally agree. &= nbsp;This really needs to be addressed and SIPCORE seems the right place.

-David




Subject: Re= : [sipcore] Locating SIP servers in a dual stack IP network
Date: Octob= er 3, 2013 8:17:45 PM EDT
To: "= ;Dale R. Worley" <worley@aria= dne.com>
Cc: <<= a href=3D"mailto:sipcore@ietf.org">sipcore@ietf.org>, "Olle E. = Johansson" <oej@edvina.net>= ;

I too think that we need to clarify the dual-stack environ= ment in SIP and support this work item in the SIP Core.

Regards,
 Rifaat



On Thu, Oct 3, 2013 at 2:55 PM, Dale R. Worley <= span dir=3D"ltr"> <worley@ariadne.= com> wrote:
> From: "Olle E. Johansson" <oej@edvina.net>
>
> We have written a draft that updates RFC 3263 to better handle dual > stack issues and prepare for another draft that clarifies Happy
> Eyeballs-like procedures for setting up connections with SIP in dual > stack networks.
>
> The document in the current version can be found here:
> http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01

> I guess the question now is if the SIPcore wg is wil= ling to adopt
> this work?

It is clear that we need to clean up any problems that SIP has in
dual-stack environments now that IPv6 usage is starting to increase.
So Sipcore should accept this work item.

Dale
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

 --_000_ACF1600D3C04D24BABD489DF98B82BB9470916BBxmbrcdx01ciscoc_-- From worley@shell01.TheWorld.com Fri Oct 4 11:02:11 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB2C21F9D95 for ; Fri, 4 Oct 2013 11:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFvY7QgQbvnL for ; Fri, 4 Oct 2013 11:02:05 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 95FA421F9C6A for ; Fri, 4 Oct 2013 11:02:01 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r94I13oA026036; Fri, 4 Oct 2013 14:01:05 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r94I12nr2372088; Fri, 4 Oct 2013 14:01:02 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r94I0wWo2353227; Fri, 4 Oct 2013 14:00:58 -0400 (EDT) Date: Fri, 4 Oct 2013 14:00:58 -0400 (EDT) Message-Id: <201310041800.r94I0wWo2353227@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <201310021920.r92JKkvX2240019@shell01.TheWorld.com> (worley@ariadne.com) References: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> <576A8B541C219D4E9CEB1DF8C19C7B881A061FED@MBX08.citservers.local> <524B2832.9040201@alum.mit.edu> <201310021920.r92JKkvX2240019@shell01.TheWorld.com> Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 18:02:11 -0000 However, we should carefully consider what we are doing here. All the recent versions, from -06 to -11, use the "hi-targeted-to-uri = addr-spec / name-addr" syntax. The WGLCs seem to have been on the -06 and -09 versions. So we're on thin ice here, changing a significant technical element of the draft. What do the chairs think, officially? Dale From pkyzivat@alum.mit.edu Fri Oct 4 12:43:44 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6617C21F9AA8 for ; Fri, 4 Oct 2013 12:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWq0xiy+J61T for ; Fri, 4 Oct 2013 12:43:38 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 72E3221F994C for ; Fri, 4 Oct 2013 12:43:38 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta03.westchester.pa.mail.comcast.net with comcast id Z0Ad1m00217dt5G537jdAy; Fri, 04 Oct 2013 19:43:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id Z7jd1m0093ZTu2S3Z7jdmP; Fri, 04 Oct 2013 19:43:37 +0000 Message-ID: <524F1A69.7000901@alum.mit.edu> Date: Fri, 04 Oct 2013 15:43:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Dale R. Worley" References: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> <576A8B541C219D4E9CEB1DF8C19C7B881A061FED@MBX08.citservers.local> <524B2832.9040201@alum.mit.edu> <201310021920.r92JKkvX2240019@shell01.TheWorld.com> <201310041800.r94I0wWo2353227@shell01.TheWorld.com> In-Reply-To: <201310041800.r94I0wWo2353227@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380915817; bh=pP+ZQFb7HMQY5SJNo3zG9XuKPBNeOe1eWzS9Rz0y+Qc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=C/FraEby2RyKGhO9xxhhfvD0LUmMVzoHVZ+1P5mzYsZkGQNLoG/k/+CU6KFMT4wwB lV40+ZUmk68ECxlVLb3z1Lo/C0iOJRE0FSe6vY9VrCQEciFJ1MrNivUoMdnSe396f/ dR51kcdPCyEwApHj56mOQ3FYBnX7/rX6Vcxuvf/MoxoU+O4xXUXXrJ+lGL+APrA5RF w6QMruNVa51LkLQ3zcYnZNKQ7ZnBhtU0ZBzG5KinO5N2i+KLYY2mFwsUyclqCTgmE1 ldjW0PxzlDeLj+6NDPmaFrs80+PMfa3i4Wu1Lf9jjvVCyZkU+4O+ESDByFd5ndxT9u Bkh2Q/mYHrAqA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 19:43:44 -0000 On 10/4/13 2:00 PM, Dale R. Worley wrote: > However, we should carefully consider what we are doing here. All the > recent versions, from -06 to -11, use the "hi-targeted-to-uri = > addr-spec / name-addr" syntax. The WGLCs seem to have been on the -06 > and -09 versions. So we're on thin ice here, changing a significant > technical element of the draft. What do the chairs think, officially? I think this flew under the radar and most people didn't even realize it was changed. I personally was in favor of the change just for reasons of consistency, but hadn't recognized the backward compatibility issue. No functionality is lost here. The only difference the change made was to allow "<" and ">" to be omitted in some cases. The only risk I see is that somebody has *deployed* code that uses addr-spec. But since the new version hasn't become an RFC yet I don't have a lot of sympathy. So I think we should be fine with this fix. Thanks, Paul From keith.drage@alcatel-lucent.com Sun Oct 6 08:16:10 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDDE21E80C3 for ; Sun, 6 Oct 2013 08:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NX+xrW6gXy3 for ; Sun, 6 Oct 2013 08:16:02 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id EDB9521E80C2 for ; Sun, 6 Oct 2013 08:16:01 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r96FFsDw009066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 6 Oct 2013 10:15:55 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r96FFquT004047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 6 Oct 2013 17:15:52 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sun, 6 Oct 2013 17:15:52 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "Dale R. Worley" Thread-Topic: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility Thread-Index: AQHOwToMO2hkoHS9nE6bHPDdf/Wp6pnnhpzw Date: Sun, 6 Oct 2013 15:15:51 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0B19EF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <576A8B541C219D4E9CEB1DF8C19C7B881A061F01@MBX08.citservers.local> <576A8B541C219D4E9CEB1DF8C19C7B881A061FED@MBX08.citservers.local> <524B2832.9040201@alum.mit.edu> <201310021920.r92JKkvX2240019@shell01.TheWorld.com> <201310041800.r94I0wWo2353227@shell01.TheWorld.com> <524F1A69.7000901@alum.mit.edu> In-Reply-To: <524F1A69.7000901@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 15:16:10 -0000 By all means post a request for WG approval of the change, but the general = working principle was compatibility where possible. Regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Paul Kyzivat > Sent: 04 October 2013 20:44 > To: Dale R. Worley > Cc: sipcore@ietf.org > Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-11: ABNF backward > compatibility >=20 > On 10/4/13 2:00 PM, Dale R. Worley wrote: > > However, we should carefully consider what we are doing here. All the > > recent versions, from -06 to -11, use the "hi-targeted-to-uri =3D > > addr-spec / name-addr" syntax. The WGLCs seem to have been on the -06 > > and -09 versions. So we're on thin ice here, changing a significant > > technical element of the draft. What do the chairs think, officially? >=20 > I think this flew under the radar and most people didn't even realize it > was changed. I personally was in favor of the change just for reasons of > consistency, but hadn't recognized the backward compatibility issue. >=20 > No functionality is lost here. The only difference the change made was > to allow "<" and ">" to be omitted in some cases. >=20 > The only risk I see is that somebody has *deployed* code that uses > addr-spec. But since the new version hasn't become an RFC yet I don't > have a lot of sympathy. >=20 > So I think we should be fine with this fix. >=20 > Thanks, > Paul >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From richard@shockey.us Mon Oct 7 06:45:40 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E023721E8097 for ; Mon, 7 Oct 2013 06:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.775 X-Spam-Level: X-Spam-Status: No, score=-100.775 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26brqPUCPbnx for ; Mon, 7 Oct 2013 06:45:35 -0700 (PDT) Received: from outbound-ss-1097.bluehost.com (outbound-ss-1097.bluehost.com [69.89.27.105]) by ietfa.amsl.com (Postfix) with SMTP id EDF5221E80A6 for ; Mon, 7 Oct 2013 06:45:34 -0700 (PDT) Received: (qmail 18852 invoked by uid 0); 7 Oct 2013 13:45:34 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy4.mail.unifiedlayer.com with SMTP; 7 Oct 2013 13:45:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=BcU8Tkw0WmgqtHKlKhp7H9xAUnSztfk3rP/+ep4/8Gs=; b=ID3L1UomA4NERXTZGfAS2wi0+A/dJKT7uRgT/LJ4kzam7Btgxr4PTpjLFTHKlgJ4xNCvk5bK0zm0ASsAsobBBecr52xDCzDL+3GgESge8zpqLvR7Pxu72ykzb9cFm13b; Received: from [71.114.100.16] (port=52053 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VTB7t-0005lC-VR; Mon, 07 Oct 2013 07:45:34 -0600 From: "Richard Shockey" To: "'Rifaat Shekh-Yusef'" , "'Dale R. Worley'" References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> In-Reply-To: Date: Mon, 7 Oct 2013 09:45:32 -0400 Message-ID: <007301cec363$7f0bc720$7d235560$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01CEC341.F7FC9820" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQFbJpQRN3alwFNin2MgbCxtzy4gFwICbfSxAMbOa4Kaui/oIA== X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.114.100.16 authed with richard@shockey.us} Cc: sipcore@ietf.org, "'Olle E. Johansson'" Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 13:45:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0074_01CEC341.F7FC9820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Rifaat Shekh-Yusef Sent: Thursday, October 03, 2013 8:18 PM To: Dale R. Worley Cc: sipcore@ietf.org; Olle E. Johansson Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network I too think that we need to clarify the dual-stack environment in SIP and support this work item in the SIP Core. Regards, Rifaat On Thu, Oct 3, 2013 at 2:55 PM, Dale R. Worley > wrote: > From: "Olle E. Johansson" > > > We have written a draft that updates RFC 3263 to better handle dual > stack issues and prepare for another draft that clarifies Happy > Eyeballs-like procedures for setting up connections with SIP in dual > stack networks. > > The document in the current version can be found here: > http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01 > I guess the question now is if the SIPcore wg is willing to adopt > this work? It is clear that we need to clean up any problems that SIP has in dual-stack environments now that IPv6 usage is starting to increase. So Sipcore should accept this work item. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore ------=_NextPart_000_0074_01CEC341.F7FC9820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1  

 

 

 

From: = sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Rifaat Shekh-Yusef
Sent: Thursday, October 03, 2013 = 8:18 PM
To: Dale R. Worley
Cc: sipcore@ietf.org; = Olle E. Johansson
Subject: Re: [sipcore] Locating SIP servers = in a dual stack IP network

 

I too = think that we need to clarify the dual-stack environment in SIP and = support this work item in the SIP Core.

 

Regards,

 Rifaat

 

 

On Thu, Oct 3, 2013 at 2:55 PM, Dale R. Worley <worley@ariadne.com> = wrote:

> = From: "Olle E. Johansson" <oej@edvina.net>

=

>
> We have = written a draft that updates RFC 3263 to better handle dual
> = stack issues and prepare for another draft that clarifies Happy
> = Eyeballs-like procedures for setting up connections with SIP in = dual
> stack networks.
>
> The document in the current = version can be found here:
> http://tools.ietf.org/html/draft-johansson-sip-dual-sta= ck-01

> I guess the question now is if the = SIPcore wg is willing to adopt
> this work?

It is clear that we need to clean up any problems that = SIP has in
dual-stack environments now that IPv6 usage is starting to = increase.
So Sipcore should accept this work item.

Dale

_______________________________________________
sipc= ore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= /o:p>

 

------=_NextPart_000_0074_01CEC341.F7FC9820-- From fluffy@iii.ca Wed Oct 9 07:48:44 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADDD11E81A0 for ; Wed, 9 Oct 2013 07:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aWrxt3mSp8x for ; Wed, 9 Oct 2013 07:48:27 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5E83B11E8196 for ; Wed, 9 Oct 2013 07:48:27 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C68A122E2C3; Wed, 9 Oct 2013 10:48:20 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Oct 2013 08:48:18 -0600 Message-Id: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> To: "SIPCORE (Session Initiation Protocol Core) WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [sipcore] Bug in RFC 4474 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 14:48:44 -0000 Bret has pointed out a bug in 4474. It has to do with the = P-Asserted-Identity header field value URI encoding when the URI has a , = ? or ;. There are basically two ways we go to resolve this=20 1) say URI with , ? or ; were not allowed=20 2) say that URI has to be inside <> brackets=20 There seem to be some evidence that #2 would cause problem for 3GPP = implementations but I don't really know. I'm not sure any reason that a = URI in a PAI should ever have , ? or ; and like to hear uses cases. Thoughts on what we should do ?=20 =20 From fluffy@cisco.com Wed Oct 9 07:57:19 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E19B21F9DE9 for ; Wed, 9 Oct 2013 07:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnYG2g+Mo-fp for ; Wed, 9 Oct 2013 07:57:12 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5913821F9E5B for ; Wed, 9 Oct 2013 07:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2654; q=dns/txt; s=iport; t=1381330632; x=1382540232; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+b6AC5OAP0hjxjVKhvW9g7dNxaXM7m+FZO4U4iTKLNI=; b=YJlC7xhLU3pzV45c04lC7aEev+DAR2nZ4aw/Gc3XJQgSh1eNdKrNr8Rg wiKE9yflYZVPQMs1znp0a+iR5uYwJXxrseCh/JhVW/szIUAtoUMKi6d7M PaKt2RLxxFs9kUXejxtjfOyp0t6/KX8+iOT78mpWNGYDN40qOOCyYvSJv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAFJuVVKtJXG9/2dsb2JhbABagwc4UsBtSoEdFnSCJQEBAQQBAQE3NAsQAgEIEQQBAQEKFAkHJwsUCQgCBA4FCId+DLkmjxICMQeDH4EEA5kykFKDJIIq X-IronPort-AV: E=Sophos;i="4.90,1064,1371081600"; d="scan'208";a="270008080" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 09 Oct 2013 14:57:04 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r99Ev4q6023335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 14:57:04 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 09:57:03 -0500 From: "Cullen Jennings (fluffy)" To: Richard Shockey Thread-Topic: [sipcore] Locating SIP servers in a dual stack IP network Thread-Index: AQHOxP/Q9wQ361y7tEye+HM1lSFNgw== Date: Wed, 9 Oct 2013 14:57:03 +0000 Message-ID: References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> In-Reply-To: <007301cec363$7f0bc720$7d235560$@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <812928A51A08C54BB2E39EE134CD2DFD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Olle E. Johansson" , "Dale R. Worley" , "sipcore@ietf.org" , Rifaat Shekh-Yusef Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 14:57:19 -0000 +1 with a minor detail. I don't think this needs to be a normative change t= o 3263. Products that implement 3263 can work just fine in v4/v6. I think t= his should be a extension to 3263 that UAs can choose to implement and can = result in better performance.=20 I'm trying to say that I happy with an RFC that products can choose to impl= ement that says the do A and AAAA in parallel. But given that 3263 does not= forbid this, I do not think it is an update to 3263, I think it is an exte= nsion.=20 Alternatively, if people make this an update, then you are not 3263 complai= nt unless you do this and thus not SIP compliant unless you do this. I am s= trongly apposed to that as this is a minor optimization that does not make = much difference in most deployments (yah yah, your registration when the ph= one first boots takes 100ms more - so what).=20 So to be clear, I support adopting this draft as a WG item but not if it is= an update to 3263.=20 On Oct 7, 2013, at 7:45 AM, Richard Shockey wrote: > +1 =20 > =20 > =20 > =20 > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f Of Rifaat Shekh-Yusef > Sent: Thursday, October 03, 2013 8:18 PM > To: Dale R. Worley > Cc: sipcore@ietf.org; Olle E. Johansson > Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network > =20 > I too think that we need to clarify the dual-stack environment in SIP and= support this work item in the SIP Core. > =20 > Regards, > Rifaat > =20 > =20 >=20 > On Thu, Oct 3, 2013 at 2:55 PM, Dale R. Worley wrote= : > > From: "Olle E. Johansson" > > > > We have written a draft that updates RFC 3263 to better handle dual > > stack issues and prepare for another draft that clarifies Happy > > Eyeballs-like procedures for setting up connections with SIP in dual > > stack networks. > > > > The document in the current version can be found here: > > http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01 >=20 > > I guess the question now is if the SIPcore wg is willing to adopt > > this work? >=20 > It is clear that we need to clean up any problems that SIP has in > dual-stack environments now that IPv6 usage is starting to increase. > So Sipcore should accept this work item. >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Wed Oct 9 08:15:37 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785DE21F9D69 for ; Wed, 9 Oct 2013 08:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dj3Q+MgUziIa for ; Wed, 9 Oct 2013 08:15:31 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 22A6C21F9CAE for ; Wed, 9 Oct 2013 08:15:29 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta02.westchester.pa.mail.comcast.net with comcast id azVU1m0050cZkys513FVHv; Wed, 09 Oct 2013 15:15:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id b3FV1m00A3ZTu2S3W3FVGK; Wed, 09 Oct 2013 15:15:29 +0000 Message-ID: <52557310.50902@alum.mit.edu> Date: Wed, 09 Oct 2013 11:15:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sipcore@ietf.org References: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> In-Reply-To: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381331729; bh=TfUsbEiT9AQzifVCe04I1GQZt1jYlMV0GZFxBHcf6PQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oGZUxgw6j0dqu+HZJMzpfH3zUoJz/RzPyiLJ5zvvHzbVjVE2syEjFNbIVBkpHsdtX gs7NA4ITFih+3O/agVRnhDlN8ol2XXVFzVmggQb4pWG2jFUkHR/6DLylvMot4wm5cl nGx+PIzG9CfVNq1ujbfDs/fQD5fK90J/yCd1UMGVDI1QG+iFdWcAFXwXXYeXKXXIiY 0WQEE4ZExwl4upJpNZglqWS525lSYniaxR209tst5FKwVpP3easFihvYn3yzFJDnzM 1MVBVTs+25E17CqcDQpP0o7hZX9uNnIL5NND51sVpT7fDr8JSa27JbJhEsQiIFyQAo uAsy1feEXgwrg== Subject: Re: [sipcore] Bug in RFC 4474 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 15:15:37 -0000 Cullen, I believe you mean 3325, not 4474. The situation with 4474 is a little different, because it didn't include addr-spec in its abnf. So its not buggy, just confusing. We got into trouble with a proposed "fix" to this in 4474bis, because the fix wasn't backward compatible. Thanks, Paul On 10/9/13 10:48 AM, Cullen Jennings wrote: > > Bret has pointed out a bug in 4474. It has to do with the P-Asserted-Identity header field value URI encoding when the URI has a , ? or ;. There are basically two ways we go to resolve this > > 1) say URI with , ? or ; were not allowed > > 2) say that URI has to be inside <> brackets > > There seem to be some evidence that #2 would cause problem for 3GPP implementations but I don't really know. I'm not sure any reason that a URI in a PAI should ever have , ? or ; and like to hear uses cases. > > > Thoughts on what we should do ? > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From fluffy@iii.ca Wed Oct 9 08:54:49 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DCE11E80F6 for ; Wed, 9 Oct 2013 08:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJnUSa1OUQs2 for ; Wed, 9 Oct 2013 08:54:44 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id A219411E81CF for ; Wed, 9 Oct 2013 08:54:35 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A556A50A89; Wed, 9 Oct 2013 11:54:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Cullen Jennings In-Reply-To: <52557310.50902@alum.mit.edu> Date: Wed, 9 Oct 2013 09:54:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6446A569-5632-4AC8-B000-A99CDCAB9C26@iii.ca> References: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> <52557310.50902@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1510) Cc: sipcore@ietf.org Subject: Re: [sipcore] Bug in RFC 3325 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 15:54:49 -0000 Ahhg - so sorry. You are right Paul. Bug in 4474 just seems embedded in = my brain :-) On Oct 9, 2013, at 9:15 AM, Paul Kyzivat wrote: > Cullen, >=20 > I believe you mean 3325, not 4474. >=20 > The situation with 4474 is a little different, because it didn't = include addr-spec in its abnf. So its not buggy, just confusing. We got = into trouble with a proposed "fix" to this in 4474bis, because the fix = wasn't backward compatible. >=20 > Thanks, > Paul >=20 > On 10/9/13 10:48 AM, Cullen Jennings wrote: >>=20 >> Bret has pointed out a bug in 4474. It has to do with the = P-Asserted-Identity header field value URI encoding when the URI has a , = ? or ;. There are basically two ways we go to resolve this >>=20 >> 1) say URI with , ? or ; were not allowed >>=20 >> 2) say that URI has to be inside <> brackets >>=20 >> There seem to be some evidence that #2 would cause problem for 3GPP = implementations but I don't really know. I'm not sure any reason that a = URI in a PAI should ever have , ? or ; and like to hear uses cases. >>=20 >>=20 >> Thoughts on what we should do ? >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Wed Oct 9 08:57:00 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A651A21F9B28 for ; Wed, 9 Oct 2013 08:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.752 X-Spam-Level: X-Spam-Status: No, score=-101.752 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMalBs2W9vtZ for ; Wed, 9 Oct 2013 08:56:58 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B0D2B21F9ACA for ; Wed, 9 Oct 2013 08:55:32 -0700 (PDT) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r99FtRdY089323 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 9 Oct 2013 10:55:28 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <52557C6A.1040200@nostrum.com> Date: Wed, 09 Oct 2013 10:55:22 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Cullen Jennings , "SIPCORE (Session Initiation Protocol Core) WG" References: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> In-Reply-To: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [sipcore] Bug in RFC 3325 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 15:57:01 -0000 On 10/9/13 09:48, Cullen Jennings wrote: > Bret has pointed out a bug in 4474. It has to do with the P-Asserted-Identity header field value URI encoding when the URI has a , ? or ;. There are basically two ways we go to resolve this > > 1) say URI with , ? or ; were not allowed > > 2) say that URI has to be inside <> brackets > > There seem to be some evidence that #2 would cause problem for 3GPP implementations but I don't really know. That doesn't make sense. The text under discussion (as Paul points out, we're talking about RFC 3325) is: "A P-Asserted-Identity header field value MUST consist of exactly one name-addr or addr-spec." And name-addr is defined thus: name-addr = [ display-name ] LAQUOT addr-spec RAQUOT Note, in particular, that display-name is optional, meaning any addr-spec can be trivially wrapped in angle brackets and become a name-addr. So your option #2 above effectively says "of these two forms that are mandatory to parse, any URI containing three specific characters needs to be in the second format." Now, if there are implementations out there that ignore the syntax defined in RFC 3325, I'm pretty comfortable asserting that they will continue to ignore corrections we issue to RFC 3325. What we say here has no impact on them. Incidentally, I don't think there's actually an ambiguity here, since ",", "?", and ";" don't have any defined meaning when used in P-Asserted-Identity. It does make the parsing of that header field somewhat of a pain, since you can't just throw a normal "multi-value name-addr/addr-spec header field" parser at it, but SIP header parsing is nothing if not a pile of exceptions on top of some loosely implied rules. This is just one more exception on the pile. /a From rifaat.ietf@gmail.com Wed Oct 9 09:43:22 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9DF11E81A9 for ; Wed, 9 Oct 2013 09:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG8fhYi6M+Dj for ; Wed, 9 Oct 2013 09:43:21 -0700 (PDT) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 32C4311E81A5 for ; Wed, 9 Oct 2013 09:42:49 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id q19so813145qeb.24 for ; Wed, 09 Oct 2013 09:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z1LfOAe4w4TJgMsThEnPD/Uk8dOdUYaUuTt2zpIwHbI=; b=mA6SNfRO5IsPuGxyZkIbTitt+5X2UhE6i7rqGu7ohIjw7QfTN1tbojQzZdJj9HqvQL pjBbmf1YuAd8wiew5duD/7BgzlLLq9G/fZFqxcyq3EzET09GpAn/MXwV9q67RUrJIcJS HTfg93T45In+viYCEBuzYl2AGmO7/+QBsMnLlTBjePmEem3Y7KglfKhrMDbcCuEd/w4c m082bZPFhT1bz9gWD7C7Ixs9pvc9hkE5EF9FEfEZHYqjtCuOJEyay2rCHsfkZTgwne0B 9qkTiEGd5AMJlK7oLCopF/6DVsJftOsK3nrGzaYGM6yD9lDEJA+J/7HUF0mNm6Y0y8+B KclA== MIME-Version: 1.0 X-Received: by 10.224.73.200 with SMTP id r8mr12433674qaj.72.1381336968339; Wed, 09 Oct 2013 09:42:48 -0700 (PDT) Received: by 10.49.16.105 with HTTP; Wed, 9 Oct 2013 09:42:48 -0700 (PDT) In-Reply-To: References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> Date: Wed, 9 Oct 2013 12:42:48 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=001a11c3e420502eeb04e8519349 Cc: "Olle E. Johansson" , "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 16:43:22 -0000 --001a11c3e420502eeb04e8519349 Content-Type: text/plain; charset=ISO-8859-1 Yeah, that makes sense to me. But I am not clear on what you mean when you say "I don't think this needs to be a *normative* change to 3263.". Are you saying that the document should be Informational instead of Standards Track? Regards, Rifaat On Wed, Oct 9, 2013 at 10:57 AM, Cullen Jennings (fluffy) wrote: > > +1 with a minor detail. I don't think this needs to be a normative change > to 3263. Products that implement 3263 can work just fine in v4/v6. I think > this should be a extension to 3263 that UAs can choose to implement and can > result in better performance. > > I'm trying to say that I happy with an RFC that products can choose to > implement that says the do A and AAAA in parallel. But given that 3263 does > not forbid this, I do not think it is an update to 3263, I think it is an > extension. > > Alternatively, if people make this an update, then you are not 3263 > complaint unless you do this and thus not SIP compliant unless you do this. > I am strongly apposed to that as this is a minor optimization that does not > make much difference in most deployments (yah yah, your registration when > the phone first boots takes 100ms more - so what). > > So to be clear, I support adopting this draft as a WG item but not if it > is an update to 3263. > > > > On Oct 7, 2013, at 7:45 AM, Richard Shockey wrote: > > > +1 > > > > > > > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Rifaat Shekh-Yusef > > Sent: Thursday, October 03, 2013 8:18 PM > > To: Dale R. Worley > > Cc: sipcore@ietf.org; Olle E. Johansson > > Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network > > > > I too think that we need to clarify the dual-stack environment in SIP > and support this work item in the SIP Core. > > > > Regards, > > Rifaat > > > > > > > > On Thu, Oct 3, 2013 at 2:55 PM, Dale R. Worley > wrote: > > > From: "Olle E. Johansson" > > > > > > We have written a draft that updates RFC 3263 to better handle dual > > > stack issues and prepare for another draft that clarifies Happy > > > Eyeballs-like procedures for setting up connections with SIP in dual > > > stack networks. > > > > > > The document in the current version can be found here: > > > http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01 > > > > > I guess the question now is if the SIPcore wg is willing to adopt > > > this work? > > > > It is clear that we need to clean up any problems that SIP has in > > dual-stack environments now that IPv6 usage is starting to increase. > > So Sipcore should accept this work item. > > > > Dale > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > --001a11c3e420502eeb04e8519349 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, that makes sense to me.
But I am = not clear on what you mean when you say "I don't think this needs to be a *normat= ive* change to 3263.". Are you saying that the document should = be Informational instead of Standards Track?

Regards,
=A0Rifaat



On Wed, O= ct 9, 2013 at 10:57 AM, Cullen Jennings (fluffy) <fluffy@cisco.com><= /span> wrote:

+1 with a minor detail. I don't think this needs to be a normative chan= ge to 3263. Products that implement 3263 can work just fine in v4/v6. I thi= nk this should be a extension to 3263 that UAs can choose to implement and = can result in better performance.

I'm trying to say that I happy with an RFC that products can choose to = implement that says the do A and AAAA in parallel. But given that 3263 does= not forbid this, I do not think it is an update to 3263, I think it is an = extension.

Alternatively, if people make this an update, then you are not 3263 complai= nt unless you do this and thus not SIP compliant unless you do this. I am s= trongly apposed to that as this is a minor optimization that does not make = much difference in most deployments (yah yah, your registration when the ph= one first boots takes 100ms more - so what).

So to be clear, I support adopting this draft as a WG item but not if it is= an update to 3263.



On Oct 7, 2013, at 7:45 AM, Richard Shockey <richard@shockey.us> wrote:

> +1
>
>
>
> From: sipcore-bounces@ietf= .org [mailto:sipcore-bounce= s@ietf.org] On Behalf Of Rifaat Shekh-Yusef
> Sent: Thursday, October 03, 2013 8:18 PM
> To: Dale R. Worley
> Cc: sipcore@ietf.org; Olle E. = Johansson
> Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network=
>
> I too think that we need to clarify the dual-stack environment in SIP = and support this work item in the SIP Core.
>
> Regards,
> =A0Rifaat
>
>
>
> On Thu, Oct 3, 2013 at 2:55 PM, Dale R. Worley <worley@ariadne.com> wrote:
> > From: "Olle E. Johansson" <oej@edvina.net>
> >
> > We have written a draft that updates RFC 3263 to better handle du= al
> > stack issues and prepare for another draft that clarifies Happy > > Eyeballs-like procedures for setting up connections with SIP in d= ual
> > stack networks.
> >
> > The document in the current version can be found here:
> > http://tools.ietf.org/html/draft-johansson-sip-du= al-stack-01
>
> > I guess the question now is if the SIPcore wg is willing to adopt=
> > this work?
>
> It is clear that we need to clean up any problems that SIP has in
> dual-stack environments now that IPv6 usage is starting to increase. > So Sipcore should accept this work item.
>
> Dale
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore


--001a11c3e420502eeb04e8519349-- From gsalguei@cisco.com Wed Oct 9 09:52:58 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A3421F9D12 for ; Wed, 9 Oct 2013 09:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L42ORmgp0AG8 for ; Wed, 9 Oct 2013 09:52:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CDDBF21F9EF6 for ; Wed, 9 Oct 2013 09:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4311; q=dns/txt; s=iport; t=1381337570; x=1382547170; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dq2FrhRjTX+wEscVxkdq31F6a5OSBgzZnOrn0kIWkNE=; b=m1zChzkBy/fzHMLmFdKBi9N1vvS+pQmB3+zkpAdxbVmb4Zpj4PEcrvO6 Dd1MeaXB2At5g6I5rTV4vLbKy3+LzXrgEygXzG7kK27lALhoQKzYbD13b cvnsxdJeuGxaTCWmdXcHuxGCoQ9s/GHUDdIND5gR7QX7rcu+6ChVXvnFX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FANKIVVKtJV2a/2dsb2JhbABagwc4UsBsSoEfFnSCJQEBAQMBAQEBawsFCwIBCBEEAQEBCh0HIQYLFAkIAgQOBQiHbAMJBgyuYA2Ja4xYgjoCMQeDH4EEA4kCjRiDGIschTaDJIIq X-IronPort-AV: E=Sophos;i="4.90,1064,1371081600"; d="scan'208";a="270154731" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 09 Oct 2013 16:52:50 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r99GqoAD029491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 16:52:50 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 11:52:49 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] Locating SIP servers in a dual stack IP network Thread-Index: AQHOveUv7oZT59pTfEykQa0II2UaOZnjW4iPgACqy4CABZivAIADOKWAgAAdjACAAALLAA== Date: Wed, 9 Oct 2013 16:52:48 +0000 Message-ID: References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.53.142] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5A883EC22C86FC4B8A3413E269E13776@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" , "sipcore@ietf.org" , "Olle E. Johansson" Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 16:52:59 -0000 On Oct 9, 2013, at 12:42 PM, Rifaat Shekh-Yusef wro= te: > Yeah, that makes sense to me. > But I am not clear on what you mean when you say "I don't think this need= s to be a *normative* change to 3263.". Are you saying that the document sh= ould be Informational instead of Standards Track? [as co-author...] This was not my understanding. What is prescribed in the draft is normativ= e and IMO should be Standards Track. Interpreted Cullen's comments as he s= imply doesn't want the "Updates: 3263" designation. =20 I'm asking because I'm unclear on the semantics: If this draft updated 3263= , wouldn't an implementation not supporting it still be 3263 compliant, but= simply not support the update (RFCXXXX) ? If it truly renders an implementation non-3263 compliant, then the argument= for not wanting this to update 3263 seems reasonable . Given that constra= int, I suppose this can be addressed with (1) standalone RFC that has text = explicitly stating this is an extension to 3263 or (2) a 3263bis effort. = Since (2) is a much more involved undertaking, I'd say (1) moves the ball f= orward and gets the desired result (normative procedures to improve perform= ance in v4/v6 environments). Cheers, Gonzalo >=20 > Regards, > Rifaat >=20 >=20 >=20 > On Wed, Oct 9, 2013 at 10:57 AM, Cullen Jennings (fluffy) wrote: >=20 > +1 with a minor detail. I don't think this needs to be a normative change= to 3263. Products that implement 3263 can work just fine in v4/v6. I think= this should be a extension to 3263 that UAs can choose to implement and ca= n result in better performance. >=20 > I'm trying to say that I happy with an RFC that products can choose to im= plement that says the do A and AAAA in parallel. But given that 3263 does n= ot forbid this, I do not think it is an update to 3263, I think it is an ex= tension. >=20 > Alternatively, if people make this an update, then you are not 3263 compl= aint unless you do this and thus not SIP compliant unless you do this. I am= strongly apposed to that as this is a minor optimization that does not mak= e much difference in most deployments (yah yah, your registration when the = phone first boots takes 100ms more - so what). >=20 > So to be clear, I support adopting this draft as a WG item but not if it = is an update to 3263. >=20 >=20 >=20 > On Oct 7, 2013, at 7:45 AM, Richard Shockey wrote: >=20 > > +1 > > > > > > > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Beh= alf Of Rifaat Shekh-Yusef > > Sent: Thursday, October 03, 2013 8:18 PM > > To: Dale R. Worley > > Cc: sipcore@ietf.org; Olle E. Johansson > > Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network > > > > I too think that we need to clarify the dual-stack environment in SIP a= nd support this work item in the SIP Core. > > > > Regards, > > Rifaat > > > > > > > > On Thu, Oct 3, 2013 at 2:55 PM, Dale R. Worley wro= te: > > > From: "Olle E. Johansson" > > > > > > We have written a draft that updates RFC 3263 to better handle dual > > > stack issues and prepare for another draft that clarifies Happy > > > Eyeballs-like procedures for setting up connections with SIP in dual > > > stack networks. > > > > > > The document in the current version can be found here: > > > http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01 > > > > > I guess the question now is if the SIPcore wg is willing to adopt > > > this work? > > > > It is clear that we need to clean up any problems that SIP has in > > dual-stack environments now that IPv6 usage is starting to increase. > > So Sipcore should accept this work item. > > > > Dale > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From fluffy@cisco.com Wed Oct 9 10:12:46 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF4F21E805F for ; Wed, 9 Oct 2013 10:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEVUbt2mlyNe for ; Wed, 9 Oct 2013 10:12:41 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1897F21E80AC for ; Wed, 9 Oct 2013 10:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4816; q=dns/txt; s=iport; t=1381338758; x=1382548358; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CnD7ayDfuYjORsmT1aMWgN8HaijVmRAacXb68qFXjwY=; b=e33rjFrUzwsOg33dz7Y1r76JE1rtS6191MBPUbN5Fj9BpG8pD/Nf68wt bolodCYRLsvsrYxkcukvSAMFD3QIcCJ1LUbApTunxA7I5g3E+lP5OVpIL zWfxodEK2+qoRXUH7piMycZBzs527tmFx8WcKay8/eOEoK4LEB+Ua/mxf s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAH+NVVKtJXG//2dsb2JhbABagwc4UsBsSoEfFnSCJQEBAQMBAQEBawsFCwIBCBEEAQEBCh0HIQYLFAkIAgQOBQiHbAMJBgyuWw2Ja4xYgjoCMQeDH4EEA4kCjRiDGIschTaDJIIq X-IronPort-AV: E=Sophos;i="4.90,1064,1371081600"; d="scan'208";a="270168645" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 09 Oct 2013 17:12:36 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r99HCDXM004853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 17:12:35 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.143]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 12:12:20 -0500 From: "Cullen Jennings (fluffy)" To: Rifaat Shekh-Yusef Thread-Topic: [sipcore] Locating SIP servers in a dual stack IP network Thread-Index: AQHOxQ6datONgAGgukq0itE39PGXHpns7x+A Date: Wed, 9 Oct 2013 17:12:20 +0000 Message-ID: References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1A0F97F092515D4CBE269249538F9387@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Olle E. Johansson" , "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:12:46 -0000 Sorry, I was not very clear.=20 I think this should be a standards track RFC.=20 However on the first page on top left, the current draft has the line=20 "Updates: 3263 (if approved) " I strongly disagree with this. It should not update 3263. It is an extensio= n to 3263. I imaging that this is here only because it is pretty confusing = in IETF what update, replace, extends, experimental etc all mean because th= ey do not mean what the common english usage might lead you to believe.=20 3263 is does not say you can't do things in parallel thought it might lead = implications to doing things sequentially. This draft has the advice to go = do A and AAAA in parallel. I've got no objections to a standards track RFC = that says to do A and AAAA in for SIP. We are not saying that every existin= g SIP device has to be modified to go do this in parallel but saying here i= s an RFC that many device may choose to implement and will make things bett= er in some way. That why I don't want it to be annotated as a update. We wa= nt to say this is good idea and here's how to do it and it's comparable wit= h how things are done today. That's why it's an extension.=20 Overall I want to minimize the churn in the SIP protocol while still allowi= ng good new idea like this to be implemented. It's a small nit - just one w= ord at the top of a spec that most people won't care about. But I will prob= ably go on and on about it, so just make that one word go away :-) And I don't want to do a 3263bis - that's lots of work and just not needed = at this point.=20 On Oct 9, 2013, at 10:42 AM, Rifaat Shekh-Yusef wrote: > Yeah, that makes sense to me. > But I am not clear on what you mean when you say "I don't think this need= s to be a *normative* change to 3263.". Are you saying that the document sh= ould be Informational instead of Standards Track? >=20 > Regards, > Rifaat >=20 >=20 >=20 > On Wed, Oct 9, 2013 at 10:57 AM, Cullen Jennings (fluffy) wrote: >=20 > +1 with a minor detail. I don't think this needs to be a normative change= to 3263. Products that implement 3263 can work just fine in v4/v6. I think= this should be a extension to 3263 that UAs can choose to implement and ca= n result in better performance. >=20 > I'm trying to say that I happy with an RFC that products can choose to im= plement that says the do A and AAAA in parallel. But given that 3263 does n= ot forbid this, I do not think it is an update to 3263, I think it is an ex= tension. >=20 > Alternatively, if people make this an update, then you are not 3263 compl= aint unless you do this and thus not SIP compliant unless you do this. I am= strongly apposed to that as this is a minor optimization that does not mak= e much difference in most deployments (yah yah, your registration when the = phone first boots takes 100ms more - so what). >=20 > So to be clear, I support adopting this draft as a WG item but not if it = is an update to 3263. >=20 >=20 >=20 > On Oct 7, 2013, at 7:45 AM, Richard Shockey wrote: >=20 > > +1 > > > > > > > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Beh= alf Of Rifaat Shekh-Yusef > > Sent: Thursday, October 03, 2013 8:18 PM > > To: Dale R. Worley > > Cc: sipcore@ietf.org; Olle E. Johansson > > Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network > > > > I too think that we need to clarify the dual-stack environment in SIP a= nd support this work item in the SIP Core. > > > > Regards, > > Rifaat > > > > > > > > On Thu, Oct 3, 2013 at 2:55 PM, Dale R. Worley wro= te: > > > From: "Olle E. Johansson" > > > > > > We have written a draft that updates RFC 3263 to better handle dual > > > stack issues and prepare for another draft that clarifies Happy > > > Eyeballs-like procedures for setting up connections with SIP in dual > > > stack networks. > > > > > > The document in the current version can be found here: > > > http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01 > > > > > I guess the question now is if the SIPcore wg is willing to adopt > > > this work? > > > > It is clear that we need to clean up any problems that SIP has in > > dual-stack environments now that IPv6 usage is starting to increase. > > So Sipcore should accept this work item. > > > > Dale > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 From worley@shell01.TheWorld.com Wed Oct 9 10:44:26 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D7121E8167 for ; Wed, 9 Oct 2013 10:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvJUUkEVOmvR for ; Wed, 9 Oct 2013 10:44:21 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1BE21E80C0 for ; Wed, 9 Oct 2013 10:44:15 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r99Hhra7027888 for ; Wed, 9 Oct 2013 13:43:55 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r99Hhqt42669701 for ; Wed, 9 Oct 2013 13:43:52 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r99Hho152669878; Wed, 9 Oct 2013 13:43:50 -0400 (EDT) Date: Wed, 9 Oct 2013 13:43:50 -0400 (EDT) Message-Id: <201310091743.r99Hho152669878@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> (fluffy@iii.ca) References: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> Subject: Re: [sipcore] Bug in RFC 4474 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:44:27 -0000 > From: Cullen Jennings > > Bret has pointed out a bug in 4474. It has to do with the > P-Asserted-Identity header field value URI encoding when the URI has > a , ? or ;. There are basically two ways we go to resolve this I think you mean RFC 3325 here. And as far as I can see, only "," is problematic, since the syntax does not provide for "header parameters": PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value *(COMMA PAssertedID-value) PAssertedID-value = name-addr / addr-spec > 1) say URI with , ? or ; were not allowed > > 2) say that URI has to be inside <> brackets > > There seem to be some evidence that #2 would cause problem for 3GPP > implementations but I don't really know. I'm not sure any reason > that a URI in a PAI should ever have , ? or ; and like to hear uses > cases. Unfortunately, "," is allowed in generic URIs, and in a number of places in SIP URIs. I expect that current practice is to not use P-Asserted-Identity URIs that contain commas by creating "users" that contain comma. But if a sender wanted to use such a URI, it could add <...>, making the PAssertedID-value into a name-addr. And the receiver is already required to be able to parse that value. Actually, isn't this one of the many places where the rule of RFC 3261 section 20 is implicitly applied? The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. In the context of implicit application of this rule whenever a syntax rule uses the construction "name-addr / addr-spec", what is the problem? Is it that some implementations do not accept the name-addr alternative, or do not consider it to be equivalent to the addr-spec alternatives when the contained URI is the same? And P-Asserted-Identity looks like it has the same problem: PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value *(COMMA PAssertedID-value) PAssertedID-value = name-addr / addr-spec Dale From brett@broadsoft.com Wed Oct 9 10:45:30 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA9721E8169 for ; Wed, 9 Oct 2013 10:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i5UuBxjxzVm for ; Wed, 9 Oct 2013 10:45:26 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id A910021E8165 for ; Wed, 9 Oct 2013 10:45:24 -0700 (PDT) Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 9 Oct 2013 10:46:26 -0700 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Wed, 9 Oct 2013 10:46:25 -0700 From: Brett Tate To: "SIPCORE (Session Initiation Protocol Core) WG" Thread-Topic: [sipcore] Bug in RFC 3325 Thread-Index: AQHOxQhk9PXEL5TI4k6WQe7lYDMy45nshzxg Date: Wed, 9 Oct 2013 17:46:25 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06302C@MBX08.citservers.local> References: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> <52557C6A.1040200@nostrum.com> In-Reply-To: <52557C6A.1040200@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Bug in RFC 3325 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:45:31 -0000 Hi, The main issue is that RFC 3261 section 20 has the following bracket rule. "The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters." NOTICE: It does not define a generic rule to indicate that all SIP headers = defined to include (name-addr / addr-spec) will follow the same RFC 3261 se= ction 20 bracket rule. However some RFCs (including RFC 3261 defined Reply= -To) do not reiterate the same statement for the headers that are also defi= ned to include (name-addr / addr-spec). The implementer does not know if i= t was an oversight or intentional. Why didn't RFC 3261 apply the same rule to Reply-To? Anybody know why? A common response on sip-implementors concerning the (name-addr / addr-spec= ) ambiguity is to always use the RFC 3261 section 20 bracket rule (even whe= n no RFC indicates to do it). However, RFC 3325 introduces a dilemma from a decode perspective for P-Asse= rted-Identity and P-Preferred-Identity since these headers do not contain p= arameters. If the header was received without using brackets, does the pre= sence of a parameter decode as 1) uri parameter, 2) malformed, or 3) assume= someone expanded the ABNF to include header-parameters. If you just look at RFC 3325, option 1 is appropriate. If you apply the RFC 3261 section 20 bracket rule, option 2 or 3 is appropr= iate. As reflected within the following thread, I can be easily convince either w= ay. :) https://lists.cs.columbia.edu/pipermail/sip-implementors/2013-October/02942= 1.html > Incidentally, I don't think there's actually an ambiguity here,=20 > since ",", "?", and ";" don't have any defined meaning when used=20 > in P-Asserted-Identity.=20 A semicolon has the same meaning within a P-Asserted-Identity's sip-uri as = it does within From sip-uri. It can separate parameters. However ignoring= RFC 3261 section 20 bracket rule, I agree that it does not cause ambiguity= concerning P-Asserted-Identity and P-Preferred-Identity since the ABNF doe= s not allow the headers to contain parameters. A comma has the same meaning within P-Asserted-Identity as it does within a= Contact. It can separate entries. The question mark has the same meaning within P-Asserted-Identity as it doe= s within a Contact sip-uri. It can seperate the headers from other part of= the sip-uri. Thus the RFC 3325 ambiguity; no text was added to indicate if the RFC 3261 = section 20 bracket rule fully applies, partially applies, or does not apply= . Anyone know why RFC 3261 section 20 bracket rule was defined for To, Fro= m, and Contact but not Reply-To, P-Asserted-Identity and P-Preferred-Identi= ty (I assume that there are others)? Thanks, Brett From worley@shell01.TheWorld.com Wed Oct 9 10:46:08 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6415121F8266 for ; Wed, 9 Oct 2013 10:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k85D+TAA4HuJ for ; Wed, 9 Oct 2013 10:45:46 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id BC93B21E816D for ; Wed, 9 Oct 2013 10:45:37 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r99HjLZW030917 for ; Wed, 9 Oct 2013 13:45:23 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r99HjK902668811 for ; Wed, 9 Oct 2013 13:45:21 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r99HjKH12657849; Wed, 9 Oct 2013 13:45:20 -0400 (EDT) Date: Wed, 9 Oct 2013 13:45:20 -0400 (EDT) Message-Id: <201310091745.r99HjKH12657849@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: (fluffy@cisco.com) References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:46:08 -0000 > From: "Cullen Jennings (fluffy)" > Alternatively, if people make this an update, then you are not 3263 > complaint unless you do this and thus not SIP compliant unless you > do this. I am strongly apposed to that as this is a minor > optimization that does not make much difference in most deployments > (yah yah, your registration when the phone first boots takes 100ms > more - so what). Strictly speaking, even if we make a normative change to 3263, products that do not implement the change are still compliant to *3263*, they're just not compliant to [whatever the new RFC number is]. Indeed, issuing a new RFC, whether or not we called it a "normative change", would simply add another checkbox on the enormously long list of "Does your SIP product implement RFC nnnn?" The customers would place whatever weight they desire on the new checkbox. The only real question seems to be the technical one of whether an implementation can (should?) be fully compliant with the new RFC and also fully compliant with 3263. If not, we need to tag 3263 as having been updated. As to whether the difference is significant in "most deployments", that is something that needs to be investigated. What is the difference in performance likely to be in environments that use IPv6? And certainly, the fraction of environments that are dual stack will be increasing rapidly over the next decade. It does look like the draft has considered how DNS record sets should be constructed to get the best SIP behavior. I worried that that might have been overlooked. (The destination domain is responsible for providing DNS records that obtain good behavior from the sender.) Dale From pkyzivat@alum.mit.edu Wed Oct 9 11:39:34 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A4321E8181 for ; Wed, 9 Oct 2013 11:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds1VY+Yg8yIE for ; Wed, 9 Oct 2013 11:39:29 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF8C21E817D for ; Wed, 9 Oct 2013 11:39:29 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta06.westchester.pa.mail.comcast.net with comcast id azl91m0030EZKEL566fUTC; Wed, 09 Oct 2013 18:39:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id b6fU1m00M3ZTu2S3M6fUT7; Wed, 09 Oct 2013 18:39:28 +0000 Message-ID: <5255A2DF.2020304@alum.mit.edu> Date: Wed, 09 Oct 2013 14:39:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sipcore@ietf.org References: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> <52557C6A.1040200@nostrum.com> In-Reply-To: <52557C6A.1040200@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381343968; bh=9ip2dJO41uguTjkt8AlbNQFtowTMksBMzNfgsoyNdsc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NIyAVtDfPR3J81HA0QYwwo2R2fwechZ+Adw4HaJrQVWQMJifRWWvruZoS9Sjtm1IZ mCURNE2fYSZBqyHr3rnfzMBYFZOuJ9oUcfZA5rRKXqyNyWH9sjoh5B7W/mMqQztZb3 gahGtb2SIe+AO7+B81wt4yMsw/7n2ZnQ+O/P+mzbapwuTewQPwnTXvgw7hokRwPpjo AvKjbPAjUzeuMNEapIKw/BZ1L8ovMZ8XzvaLBJIZlj8UDZ0/UCRy+6K6JJodRqef+6 KLR80qJ/eQVJJEQpQjjboxWW9+SazSMymZlZt/7hQjaa0/itao18bRPgNkKf9+bj4M BE9dcMBBTO3aQ== Subject: Re: [sipcore] Bug in RFC 3325 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 18:39:34 -0000 I think I'm in agreement with Adam, but am not certain about his position. IMO there is *no bug* in 3325 in this regard. Its inconsistent with the "normal" processing of headers that have name-addr/addr-spec, but that's just ugly, not a bug. The reason for the special rules in 3261 is because without them the syntax is ambiguous. E.g., in: To: sip:foo@bar,baz the comma could introduce a sip uri parameter, or it could end the sip uri and introduce a To header field parameter. But P-Asserted-Identity has no syntax for header field parameters, or anything else, after the name-addr/addr-spec, so there is no ambiguity. The comma unambiguously introduces a sip URI parameter. As Adam notes, this is unpleasant for implementers. Sorry. Thanks, Paul On 10/9/13 11:55 AM, Adam Roach wrote: > On 10/9/13 09:48, Cullen Jennings wrote: >> Bret has pointed out a bug in 4474. It has to do with the >> P-Asserted-Identity header field value URI encoding when the URI has a >> , ? or ;. There are basically two ways we go to resolve this >> >> 1) say URI with , ? or ; were not allowed >> >> 2) say that URI has to be inside <> brackets >> >> There seem to be some evidence that #2 would cause problem for 3GPP >> implementations but I don't really know. > > That doesn't make sense. The text under discussion (as Paul points out, > we're talking about RFC 3325) is: > > "A P-Asserted-Identity header field value MUST consist of exactly one > name-addr or addr-spec." > > And name-addr is defined thus: > > name-addr = [ display-name ] LAQUOT addr-spec RAQUOT > > Note, in particular, that display-name is optional, meaning any > addr-spec can be trivially wrapped in angle brackets and become a > name-addr. So your option #2 above effectively says "of these two forms > that are mandatory to parse, any URI containing three specific > characters needs to be in the second format." > > Now, if there are implementations out there that ignore the syntax > defined in RFC 3325, I'm pretty comfortable asserting that they will > continue to ignore corrections we issue to RFC 3325. What we say here > has no impact on them. > > Incidentally, I don't think there's actually an ambiguity here, since > ",", "?", and ";" don't have any defined meaning when used in > P-Asserted-Identity. It does make the parsing of that header field > somewhat of a pain, since you can't just throw a normal "multi-value > name-addr/addr-spec header field" parser at it, but SIP header parsing > is nothing if not a pile of exceptions on top of some loosely implied > rules. This is just one more exception on the pile. > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@alum.mit.edu Wed Oct 9 11:49:39 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE5321E8159 for ; Wed, 9 Oct 2013 11:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lexO7gHT+1nm for ; Wed, 9 Oct 2013 11:49:34 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id DA3A821E8092 for ; Wed, 9 Oct 2013 11:49:32 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta13.westchester.pa.mail.comcast.net with comcast id b0Gi1m0080bG4ec5D6pY5u; Wed, 09 Oct 2013 18:49:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id b6pX1m00z3ZTu2S3P6pYoE; Wed, 09 Oct 2013 18:49:32 +0000 Message-ID: <5255A53A.1070301@alum.mit.edu> Date: Wed, 09 Oct 2013 14:49:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sipcore@ietf.org References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> <201310091745.r99HjKH12657849@shell01.TheWorld.com> In-Reply-To: <201310091745.r99HjKH12657849@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381344572; bh=uDejUUtzn+bMal89CkH9fJLNsPcO4iVYIP9jIoPwsXY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RrPwyxXp8sxkCs9QtYIXyWn0xFI/vpC0GRw1C1SfgGTjZqmS0rnYVMjT7XXLy+txD KVvIQ9Ww5FOCv+Ghs5Xa2j75HsVrB+LXqiOeCW44717Z11iQwExRnGqcK+2CGBwcSz tz/87WajK63FTd8I7kK/kPBbLXlv0wUfW4ASzM1Mpzendfd1Wt30/vK4GXHKctgnRx 5XXdEp9biODRFURAcXCdaduzsn0UuDY+jZe3v2xAq98mPhi2+N0MzVA3Y3PJ3m3I/1 acA9YLgGqhnG+3gCI8dqezd3mJG66RHFbJ7YfjQ/u7vXSMKyrVw6Bnskol8O1j2xMm H+gydC3+auXng== Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 18:49:39 -0000 (as individual) I agree with Cullen's intent here. If others do too, then we just need to agree on the best way to achieve that intent. If the behavior in this draft is already legal according to RFC3263, then why does it need to be normative? Couldn't it be an informative RFC that describes a more efficient way to use 3263? Thanks, Paul On 10/9/13 1:45 PM, Dale R. Worley wrote: >> From: "Cullen Jennings (fluffy)" > >> Alternatively, if people make this an update, then you are not 3263 >> complaint unless you do this and thus not SIP compliant unless you >> do this. I am strongly apposed to that as this is a minor >> optimization that does not make much difference in most deployments >> (yah yah, your registration when the phone first boots takes 100ms >> more - so what). > > Strictly speaking, even if we make a normative change to 3263, > products that do not implement the change are still compliant to > *3263*, they're just not compliant to [whatever the new RFC number > is]. > > Indeed, issuing a new RFC, whether or not we called it a "normative > change", would simply add another checkbox on the enormously long list > of "Does your SIP product implement RFC nnnn?" The customers would > place whatever weight they desire on the new checkbox. The only real > question seems to be the technical one of whether an implementation > can (should?) be fully compliant with the new RFC and also fully > compliant with 3263. If not, we need to tag 3263 as having been > updated. > > As to whether the difference is significant in "most deployments", > that is something that needs to be investigated. What is the > difference in performance likely to be in environments that use IPv6? > And certainly, the fraction of environments that are dual stack will > be increasing rapidly over the next decade. > > It does look like the draft has considered how DNS record sets should > be constructed to get the best SIP behavior. I worried that that > might have been overlooked. (The destination domain is responsible > for providing DNS records that obtain good behavior from the sender.) > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From brett@broadsoft.com Wed Oct 9 12:12:57 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6AF21F9A0C for ; Wed, 9 Oct 2013 12:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eu8+EgdlEujQ for ; Wed, 9 Oct 2013 12:12:53 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2580421E8185 for ; Wed, 9 Oct 2013 12:12:48 -0700 (PDT) Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 9 Oct 2013 12:13:52 -0700 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Wed, 9 Oct 2013 12:13:52 -0700 From: Brett Tate To: "SIPCORE (Session Initiation Protocol Core) WG" Thread-Topic: [sipcore] Bug in RFC 3325 Thread-Index: AQHOxQhk9PXEL5TI4k6WQe7lYDMy45nshzxggAA1OzA= Date: Wed, 9 Oct 2013 19:13:51 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A0630A2@MBX08.citservers.local> References: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> <52557C6A.1040200@nostrum.com> <576A8B541C219D4E9CEB1DF8C19C7B881A06302C@MBX08.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A06302C@MBX08.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Bug in RFC 3325 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 19:12:57 -0000 You can ignore my mentioning of Reply-To. The rule is within RFC 3261 sect= ion 20.31. "Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, question mark, or semicolon." > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Brett Tate > Sent: Wednesday, October 09, 2013 1:46 PM > To: SIPCORE (Session Initiation Protocol Core) WG > Subject: Re: [sipcore] Bug in RFC 3325 >=20 > Hi, >=20 > The main issue is that RFC 3261 section 20 has the following bracket > rule. >=20 > "The Contact, From, and To header fields contain a URI. If the URI > contains a comma, question mark or semicolon, the URI MUST be > enclosed in angle brackets (< and >). Any URI parameters are > contained within these brackets. If the URI is not enclosed in angle > brackets, any semicolon-delimited parameters are header-parameters, > not URI parameters." >=20 > NOTICE: It does not define a generic rule to indicate that all SIP > headers defined to include (name-addr / addr-spec) will follow the same > RFC 3261 section 20 bracket rule. However some RFCs (including RFC > 3261 defined Reply-To) do not reiterate the same statement for the > headers that are also defined to include (name-addr / addr-spec). The > implementer does not know if it was an oversight or intentional. >=20 > Why didn't RFC 3261 apply the same rule to Reply-To? Anybody know why? >=20 > A common response on sip-implementors concerning the (name-addr / addr- > spec) ambiguity is to always use the RFC 3261 section 20 bracket rule > (even when no RFC indicates to do it). >=20 > However, RFC 3325 introduces a dilemma from a decode perspective for P- > Asserted-Identity and P-Preferred-Identity since these headers do not > contain parameters. If the header was received without using brackets, > does the presence of a parameter decode as 1) uri parameter, 2) > malformed, or 3) assume someone expanded the ABNF to include header- > parameters. >=20 > If you just look at RFC 3325, option 1 is appropriate. >=20 > If you apply the RFC 3261 section 20 bracket rule, option 2 or 3 is > appropriate. >=20 > As reflected within the following thread, I can be easily convince > either way. :) >=20 > https://lists.cs.columbia.edu/pipermail/sip-implementors/2013- > October/029421.html >=20 >=20 > > Incidentally, I don't think there's actually an ambiguity here, > > since ",", "?", and ";" don't have any defined meaning when used > > in P-Asserted-Identity. >=20 > A semicolon has the same meaning within a P-Asserted-Identity's sip-uri > as it does within From sip-uri. It can separate parameters. However > ignoring RFC 3261 section 20 bracket rule, I agree that it does not > cause ambiguity concerning P-Asserted-Identity and P-Preferred-Identity > since the ABNF does not allow the headers to contain parameters. >=20 > A comma has the same meaning within P-Asserted-Identity as it does > within a Contact. It can separate entries. >=20 > The question mark has the same meaning within P-Asserted-Identity as it > does within a Contact sip-uri. It can seperate the headers from other > part of the sip-uri. >=20 > Thus the RFC 3325 ambiguity; no text was added to indicate if the RFC > 3261 section 20 bracket rule fully applies, partially applies, or does > not apply. Anyone know why RFC 3261 section 20 bracket rule was > defined for To, From, and Contact but not Reply-To, P-Asserted-Identity > and P-Preferred-Identity (I assume that there are others)? >=20 > Thanks, > Brett >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Wed Oct 9 12:13:37 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E3A21E8195 for ; Wed, 9 Oct 2013 12:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.243 X-Spam-Level: X-Spam-Status: No, score=-0.243 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlmEYcyIs5cE for ; Wed, 9 Oct 2013 12:13:32 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id D55F621E8199 for ; Wed, 9 Oct 2013 12:13:21 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta09.westchester.pa.mail.comcast.net with comcast id azum1m0050EZKEL597DMzY; Wed, 09 Oct 2013 19:13:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id b7DM1m0083ZTu2S3M7DMiu; Wed, 09 Oct 2013 19:13:21 +0000 Message-ID: <5255AAD0.1030000@alum.mit.edu> Date: Wed, 09 Oct 2013 15:13:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sipcore@ietf.org References: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> <201310091743.r99Hho152669878@shell01.TheWorld.com> In-Reply-To: <201310091743.r99Hho152669878@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381346001; bh=a+lUtm94O/Dg+N+6UgRC6gfpzkEY8RFXc9+Ztsfh9Cc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UVKYZITZpPecEs+n/CO8KWmfk+daXgge55aIeiDpVdt3yGFRU+1+WjY2RKHYS8PRj 3jOgUW1Xdrhc60kv1ujxFM4oHKE4IsVtytFGSELqfp945W6rEKa+J2XJHMM1aQ4801 2cr1Jk606IckuNhG498e7gZdmh/DUxQDUTqaab/SC+BH7uQxsfCQAbs96tImbdUY3k kGeDytuEcMWqXtwVZdrCsMrRQAEN70mt6/zbwxJTRTRojKCkhsfaJlZl7g/TMkjhBS fZdfOQdLZrPYxZe433jb9xDIB5dahQYqwZAr94xmKJ6p5oml7bwFghtFiCdFsa77kM 7vDjZPA/K0MMQ== Subject: Re: [sipcore] Bug in RFC 4474 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 19:13:37 -0000 Oops! Obviously my earlier reply was wrong, because I suggested that PAID didn't allow anything after the name-addr/addr-spec. Since it allows comma it does have an ambiguity that needs some clarification to resolve. I suppose *in principle* (using arbitary amounts of look ahead) it would be possible to resolve the ambiguity. But that is unreasonable. So I take it all back and agree there is a bug. Sorry, Paul On 10/9/13 1:43 PM, Dale R. Worley wrote: >> From: Cullen Jennings >> >> Bret has pointed out a bug in 4474. It has to do with the >> P-Asserted-Identity header field value URI encoding when the URI has >> a , ? or ;. There are basically two ways we go to resolve this > > I think you mean RFC 3325 here. And as far as I can see, only "," is > problematic, since the syntax does not provide for "header > parameters": > > PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value > *(COMMA PAssertedID-value) > PAssertedID-value = name-addr / addr-spec > >> 1) say URI with , ? or ; were not allowed >> >> 2) say that URI has to be inside <> brackets >> >> There seem to be some evidence that #2 would cause problem for 3GPP >> implementations but I don't really know. I'm not sure any reason >> that a URI in a PAI should ever have , ? or ; and like to hear uses >> cases. > > Unfortunately, "," is allowed in generic URIs, and in a number of > places in SIP URIs. > > I expect that current practice is to not use P-Asserted-Identity URIs > that contain commas by creating "users" that contain comma. > > But if a sender wanted to use such a URI, it could add <...>, making > the PAssertedID-value into a name-addr. And the receiver is already > required to be able to parse that value. > > Actually, isn't this one of the many places where the rule of RFC 3261 > section 20 is implicitly applied? > > The Contact, From, and To header fields contain a URI. If the URI > contains a comma, question mark or semicolon, the URI MUST be > enclosed in angle brackets (< and >). Any URI parameters are > contained within these brackets. If the URI is not enclosed in angle > brackets, any semicolon-delimited parameters are header-parameters, > not URI parameters. > > In the context of implicit application of this rule whenever a syntax > rule uses the construction "name-addr / addr-spec", what is the > problem? Is it that some implementations do not accept the name-addr > alternative, or do not consider it to be equivalent to the addr-spec > alternatives when the contained URI is the same? > > And P-Asserted-Identity looks like it has the same problem: > > PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value > *(COMMA PAssertedID-value) > PAssertedID-value = name-addr / addr-spec > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From rifaat.ietf@gmail.com Wed Oct 9 12:33:03 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A63F21E81A1 for ; Wed, 9 Oct 2013 12:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCd8d92bpH0M for ; Wed, 9 Oct 2013 12:33:02 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B55F721E8196 for ; Wed, 9 Oct 2013 12:32:59 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id x7so1156729qeu.19 for ; Wed, 09 Oct 2013 12:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i6jGghRCihDY/HsVMkt0cVhUmnImqJ2ihGaatQnRopA=; b=ce3snjQHL4SrhxLXFuTLOtS8BA0bnCdDouQNaw9XC52ZLWGMk4qmnrF5FSux/Olfa9 L/dBvg3OtnqFGe1C9y7bjjycoaTMtXAFrNBoEnxZ6dgMMMdrNsKfZSwyCMAmpmVJFgie K4dNMHM1AfJlAohjH4oZIyziyasQPa9AbQa8f24aYMk9rbnKDnnjI167+wWxYAKxABkn g/rUZywzsggU9Dq1+20GksHmbcsoZzLUMnl8nBXPyuyF3CQLn1rVcn0BIQVwVJ78tNSs XjD3UXWrT6qnmL1IwQyTRjtt6xyAc5msQCUP0Y0r0DpI7NQN1Rzuy4McU5EKWuqtp9/h /o0A== MIME-Version: 1.0 X-Received: by 10.229.47.71 with SMTP id m7mr473112qcf.25.1381347178808; Wed, 09 Oct 2013 12:32:58 -0700 (PDT) Received: by 10.49.16.105 with HTTP; Wed, 9 Oct 2013 12:32:58 -0700 (PDT) In-Reply-To: <5255A53A.1070301@alum.mit.edu> References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> <201310091745.r99HjKH12657849@shell01.TheWorld.com> <5255A53A.1070301@alum.mit.edu> Date: Wed, 9 Oct 2013 15:32:58 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1133b3e4e7a5b804e853f3fd Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 19:33:03 -0000 --001a1133b3e4e7a5b804e853f3fd Content-Type: text/plain; charset=ISO-8859-1 I too agree with Cullen's intent, but was confused by the "normative" comment. I agree that Informational draft might be sufficient in this case. Regards, Rifaat On Wed, Oct 9, 2013 at 2:49 PM, Paul Kyzivat wrote: > (as individual) > > I agree with Cullen's intent here. > If others do too, then we just need to agree on the best way to achieve > that intent. > > If the behavior in this draft is already legal according to RFC3263, then > why does it need to be normative? Couldn't it be an informative RFC that > describes a more efficient way to use 3263? > > Thanks, > Paul > > > > On 10/9/13 1:45 PM, Dale R. Worley wrote: > >> From: "Cullen Jennings (fluffy)" >>> >> >> Alternatively, if people make this an update, then you are not 3263 >>> complaint unless you do this and thus not SIP compliant unless you >>> do this. I am strongly apposed to that as this is a minor >>> optimization that does not make much difference in most deployments >>> (yah yah, your registration when the phone first boots takes 100ms >>> more - so what). >>> >> >> Strictly speaking, even if we make a normative change to 3263, >> products that do not implement the change are still compliant to >> *3263*, they're just not compliant to [whatever the new RFC number >> is]. >> >> Indeed, issuing a new RFC, whether or not we called it a "normative >> change", would simply add another checkbox on the enormously long list >> of "Does your SIP product implement RFC nnnn?" The customers would >> place whatever weight they desire on the new checkbox. The only real >> question seems to be the technical one of whether an implementation >> can (should?) be fully compliant with the new RFC and also fully >> compliant with 3263. If not, we need to tag 3263 as having been >> updated. >> >> As to whether the difference is significant in "most deployments", >> that is something that needs to be investigated. What is the >> difference in performance likely to be in environments that use IPv6? >> And certainly, the fraction of environments that are dual stack will >> be increasing rapidly over the next decade. >> >> It does look like the draft has considered how DNS record sets should >> be constructed to get the best SIP behavior. I worried that that >> might have been overlooked. (The destination domain is responsible >> for providing DNS records that obtain good behavior from the sender.) >> >> Dale >> ______________________________**_________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/**listinfo/sipcore >> >> > ______________________________**_________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/**listinfo/sipcore > --001a1133b3e4e7a5b804e853f3fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I too agree with Cullen's intent, but was confused by = the "normative" comment.
I agree that Informational draft mig= ht be sufficient in this case.

Regards,
=A0Rifaat



On Wed, Oct 9, 2013 at 2:49 PM, Paul Kyzivat <p= kyzivat@alum.mit.edu> wrote:
(as individual)

I agree with Cullen's intent here.
If others do too, then we just need to agree on the best way to achieve tha= t intent.

If the behavior in this draft is already legal according to RFC3263, then w= hy does it need to be normative? Couldn't it be an informative RFC that= describes a more efficient way to use 3263?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul



On 10/9/13 1:45 PM, Dale R. Worley wrote:
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>

Alternatively, if people make this an update, then you are not 3263
complaint unless you do this and thus not SIP compliant unless you
do this. I am strongly apposed to that as this is a minor
optimization that does not make much difference in most deployments
(yah yah, your registration when the phone first boots takes 100ms
more - so what).

Strictly speaking, even if we make a normative change to 3263,
products that do not implement the change are still compliant to
*3263*, they're just not compliant to [whatever the new RFC number
is].

Indeed, issuing a new RFC, whether or not we called it a "normative change", would simply add another checkbox on the enormously long list=
of "Does your SIP product implement RFC nnnn?" =A0The customers w= ould
place whatever weight they desire on the new checkbox. =A0The only real
question seems to be the technical one of whether an implementation
can (should?) be fully compliant with the new RFC and also fully
compliant with 3263. =A0If not, we need to tag 3263 as having been
updated.

As to whether the difference is significant in "most deployments"= ,
that is something that needs to be investigated. =A0What is the
difference in performance likely to be in environments that use IPv6?
And certainly, the fraction of environments that are dual stack will
be increasing rapidly over the next decade.

It does look like the draft has considered how DNS record sets should
be constructed to get the best SIP behavior. =A0I worried that that
might have been overlooked. =A0(The destination domain is responsible
for providing DNS records that obtain good behavior from the sender.)

Dale
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--001a1133b3e4e7a5b804e853f3fd-- From brett@broadsoft.com Wed Oct 9 12:48:43 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215D921E81AF for ; Wed, 9 Oct 2013 12:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-f1jJu12z1p for ; Wed, 9 Oct 2013 12:48:38 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 0C80321E8190 for ; Wed, 9 Oct 2013 12:48:37 -0700 (PDT) Received: from CASUMHUB03.citservers.local (172.16.98.219) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 9 Oct 2013 12:49:28 -0700 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Wed, 9 Oct 2013 12:49:28 -0700 From: Brett Tate To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Bug in RFC 4474 Thread-Index: AQHOxRdcdBomEiVw5kK8+PCKMOvpy5nssXww Date: Wed, 9 Oct 2013 19:49:27 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A0630DA@MBX08.citservers.local> References: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> <201310091743.r99Hho152669878@shell01.TheWorld.com> In-Reply-To: <201310091743.r99Hho152669878@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Bug in RFC 4474 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 19:48:43 -0000 > In the context of implicit application of this rule=20 > whenever a syntax rule uses the construction=20 > "name-addr / addr-spec", what is the problem? =20 RFC 3325 introduces a dilemma from a decode perspective for P-Asserted-Iden= tity and P-Preferred-Identity since these headers do not contain parameters= . If the header was received without using brackets, does the presence of = a parameter decode as 1) uri parameter, 2) malformed, or 3) assume someone = expanded the ABNF to include header-parameters. If you just look at RFC 3325, option 1 is appropriate. If you apply the RFC 3261 section 20 bracket rule, option 2 or 3 is appropr= iate. > Is it that some implementations do not accept the=20 > name-addr alternative, or do not consider it to be=20 > equivalent to the addr-spec alternatives when the=20 > contained URI is the same? It is the applicability of the bracket rule from a decode perspective when = headers such as P-Asserted-Identity and P-Preferred-Identity contain semi-c= olon (or comma or question mark) when there are no brackets. >From RFC perspective, the RFC 3261 section 20 bracket rule explicitly appli= es to To, From, and Contact. There is nothing to indicate that it fully ap= plies, partially applies, or does not apply to P-Asserted-Identity and P-Pr= eferred-Identity. "The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters." Thanks, Brett From gsalguei@cisco.com Wed Oct 9 13:23:54 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6501B21E81B3 for ; Wed, 9 Oct 2013 13:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJtp9hzfNiSB for ; Wed, 9 Oct 2013 13:23:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DC67121E81B6 for ; Wed, 9 Oct 2013 13:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2884; q=dns/txt; s=iport; t=1381350218; x=1382559818; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kALlbtoWUTeznhpfgDPC3skTD2yZ0BZ1zDbFczwuhRI=; b=RQG0ykFdrhuF4JV4qELEPkojqG6wzrdmDHAg/TRNa5J81F9q+jfyqGCw WKaVDHgoTccg/Oh1n59YjCSS2HLCWtf9pemObqZsoIicp2z+5Q0XZ2OvA 59U4THIHqIMSWqkpLP7Y1NbCEInaejaVIJfKvMLoT3W0puuzjTyNi6Ca1 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAIm6VVKtJV2Y/2dsb2JhbABaDoJ5OFLAbUqBHxZ0giUBAQEDAQEBATc0CxACAQgOBwMKFBAnCyUCBA4FCId4Bgy4bASPEgIxB4MfgQQDqgSCZT+CKg X-IronPort-AV: E=Sophos;i="4.90,1066,1371081600"; d="scan'208";a="270187267" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 09 Oct 2013 20:23:37 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r99KNbL8018695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 20:23:37 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 15:23:36 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [sipcore] Locating SIP servers in a dual stack IP network Thread-Index: AQHOxRdS7oZT59pTfEykQa0II2UaOZntCjUAgAAaSoA= Date: Wed, 9 Oct 2013 20:23:36 +0000 Message-ID: References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> <201310091745.r99HjKH12657849@shell01.TheWorld.com> <5255A53A.1070301@alum.mit.edu> In-Reply-To: <5255A53A.1070301@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.53.142] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 20:23:54 -0000 On Oct 9, 2013, at 2:49 PM, Paul Kyzivat wrote: > (as individual) >=20 > I agree with Cullen's intent here. > If others do too, then we just need to agree on the best way to achieve t= hat intent. >=20 > If the behavior in this draft is already legal according to RFC3263, then= why does it need to be normative? Couldn't it be an informative RFC that d= escribes a more efficient way to use 3263? There is likely some level of subjectivity here, but isn't the more efficie= nt way a normative procedure that is a protocol directive with implementati= on impacts? That strikes me as Standards Track. Gonzalo >=20 > Thanks, > Paul >=20 >=20 > On 10/9/13 1:45 PM, Dale R. Worley wrote: >>> From: "Cullen Jennings (fluffy)" >>=20 >>> Alternatively, if people make this an update, then you are not 3263 >>> complaint unless you do this and thus not SIP compliant unless you >>> do this. I am strongly apposed to that as this is a minor >>> optimization that does not make much difference in most deployments >>> (yah yah, your registration when the phone first boots takes 100ms >>> more - so what). >>=20 >> Strictly speaking, even if we make a normative change to 3263, >> products that do not implement the change are still compliant to >> *3263*, they're just not compliant to [whatever the new RFC number >> is]. >>=20 >> Indeed, issuing a new RFC, whether or not we called it a "normative >> change", would simply add another checkbox on the enormously long list >> of "Does your SIP product implement RFC nnnn?" The customers would >> place whatever weight they desire on the new checkbox. The only real >> question seems to be the technical one of whether an implementation >> can (should?) be fully compliant with the new RFC and also fully >> compliant with 3263. If not, we need to tag 3263 as having been >> updated. >>=20 >> As to whether the difference is significant in "most deployments", >> that is something that needs to be investigated. What is the >> difference in performance likely to be in environments that use IPv6? >> And certainly, the fraction of environments that are dual stack will >> be increasing rapidly over the next decade. >>=20 >> It does look like the draft has considered how DNS record sets should >> be constructed to get the best SIP behavior. I worried that that >> might have been overlooked. (The destination domain is responsible >> for providing DNS records that obtain good behavior from the sender.) >>=20 >> Dale >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From worley@shell01.TheWorld.com Thu Oct 10 08:22:12 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECC021F864D for ; Thu, 10 Oct 2013 08:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mCf-uW9Pu3v for ; Thu, 10 Oct 2013 08:22:03 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id EA73821F9468 for ; Thu, 10 Oct 2013 08:21:55 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r9AFL3FW028848 for ; Thu, 10 Oct 2013 11:21:05 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r9AFL3HD2718546 for ; Thu, 10 Oct 2013 11:21:03 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r9AFL2QU2714949; Thu, 10 Oct 2013 11:21:02 -0400 (EDT) Date: Thu, 10 Oct 2013 11:21:02 -0400 (EDT) Message-Id: <201310101521.r9AFL2QU2714949@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <576A8B541C219D4E9CEB1DF8C19C7B881A06302C@MBX08.citservers.local> (brett@broadsoft.com) References: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> <52557C6A.1040200@nostrum.com> <576A8B541C219D4E9CEB1DF8C19C7B881A06302C@MBX08.citservers.local> Subject: Re: [sipcore] Bug in RFC 3325 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:22:12 -0000 > From: Brett Tate > However, RFC 3325 introduces a dilemma from a decode perspective for > P-Asserted-Identity and P-Preferred-Identity since these headers do > not contain parameters. If the header was received without using > brackets, does the presence of a parameter decode as 1) uri > parameter, 2) malformed, or 3) assume someone expanded the ABNF to > include header-parameters. > > If you just look at RFC 3325, option 1 is appropriate. > > If you apply the RFC 3261 section 20 bracket rule, option 2 or 3 is > appropriate. Yuck. Given the possibility that someone has added header-parameters, then the grammar as specified (without assuming section 20) is ambiguous. So "the answer" depends on actual practice. Fortunately, 3GPP is a fairly small community. Can we lobby everybody to start applying section 20 when they send requests? Dale From adam@nostrum.com Thu Oct 10 08:28:56 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBBC21F9A6C for ; Thu, 10 Oct 2013 08:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.176 X-Spam-Level: X-Spam-Status: No, score=-102.176 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDHcC8EL+hPf for ; Thu, 10 Oct 2013 08:28:55 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4653E21F9C05 for ; Thu, 10 Oct 2013 08:28:32 -0700 (PDT) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9AFSPP7051406 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 10:28:27 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5256C794.4020309@nostrum.com> Date: Thu, 10 Oct 2013 10:28:20 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Dale R. Worley" , sipcore@ietf.org References: <3D5EFC0C-99A1-4F0E-88C0-C3BD9F5CE035@iii.ca> <52557C6A.1040200@nostrum.com> <576A8B541C219D4E9CEB1DF8C19C7B881A06302C@MBX08.citservers.local> <201310101521.r9AFL2QU2714949@shell01.TheWorld.com> In-Reply-To: <201310101521.r9AFL2QU2714949@shell01.TheWorld.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Subject: Re: [sipcore] Bug in RFC 3325 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:28:57 -0000 On 10/10/13 10:21, Dale R. Worley wrote: >> From: Brett Tate >> However, RFC 3325 introduces a dilemma from a decode perspective for >> P-Asserted-Identity and P-Preferred-Identity since these headers do >> not contain parameters. If the header was received without using >> brackets, does the presence of a parameter decode as 1) uri >> parameter, 2) malformed, or 3) assume someone expanded the ABNF to >> include header-parameters. >> >> If you just look at RFC 3325, option 1 is appropriate. >> >> If you apply the RFC 3261 section 20 bracket rule, option 2 or 3 is >> appropriate. > Yuck. > > Given the possibility that someone has added header-parameters, then > the grammar as specified (without assuming section 20) is ambiguous. > So "the answer" depends on actual practice. Fortunately, 3GPP is a > fairly small community. > > Can we lobby everybody to start applying section 20 when they send > requests? > That's the proposal made by the erratum on the table, and (I think) the cleanest way to deal with the situation. /a From brett@broadsoft.com Thu Oct 10 10:14:54 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBAB11E817E for ; Thu, 10 Oct 2013 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBzaIF2ng2XY for ; Thu, 10 Oct 2013 10:14:50 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 26D7B11E8179 for ; Thu, 10 Oct 2013 10:14:49 -0700 (PDT) Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 10 Oct 2013 10:15:54 -0700 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Thu, 10 Oct 2013 10:15:53 -0700 From: Brett Tate To: "sipcore@ietf.org" Thread-Topic: headers with name-addr / addr-spec ambiguity issue Thread-Index: Ac7F3Dd/2JgZoKHQSiS7S1Bpq2sGgA== Date: Thu, 10 Oct 2013 17:15:53 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A063268@MBX08.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] headers with name-addr / addr-spec ambiguity issue X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 17:14:54 -0000 Hi, Since the issue with RFC 3325 is currently being discussed, I thought that = I'd mention that the following headers also appear to have same issue of th= eir corresponding RFC not indicating to use the RFC 3261 section 20 bracket= rule. I only listed headers that appear on http://www.iana.org/assignment= s/sip-parameters/sip-parameters.xhtml. I assume that errata should also opened on these RFCs to contain the follow= ing sentence. "If the URI contains a comma, question mark or semicolon, the URI MUST be e= nclosed in angle brackets (< and >)." Thanks, Brett ---- RFC 3515: Refer-To =3D ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI generic-param) RFC 5002: P-Profile-Key =3D "P-Profile-Key" HCOLON (name-addr / addr-spec) *( SEMI generic-param ) RFC 5318: P-Refused-URI-List =3D "P-Refused-URI-List" HCOLON uri-list-entry *(COMMA uri-list-entry) uri-list-entry =3D ( name-addr / addr-spec ) *( SEMI refused-param ) RFC 5360: Permission-Missing =3D "Permission-Missing" HCOLON per-miss-spec *( COMMA per-miss-spec ) per-miss-spec =3D ( name-addr / addr-spec ) *( SEMI generic-param ) RFC 5502: P-Served-User =3D "P-Served-User" HCOLON PServedUser-value *(SEMI served-user-param) PServedUser-value =3D name-addr / addr-spec This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it. From pkyzivat@alum.mit.edu Thu Oct 10 14:57:04 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E4721E813E for ; Thu, 10 Oct 2013 14:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.254 X-Spam-Level: X-Spam-Status: No, score=-0.254 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEdP+ZMmgqY4 for ; Thu, 10 Oct 2013 14:57:00 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 3377021E80F0 for ; Thu, 10 Oct 2013 14:56:56 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA11.westchester.pa.mail.comcast.net with comcast id bYVv1m0041YDfWL5BZwsZR; Thu, 10 Oct 2013 21:56:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id bZws1m0093ZTu2S3gZwsFZ; Thu, 10 Oct 2013 21:56:52 +0000 Message-ID: <525722A3.3080902@alum.mit.edu> Date: Thu, 10 Oct 2013 17:56:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> <201310091745.r99HjKH12657849@shell01.TheWorld.com> <5255A53A.1070301@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381442212; bh=9QZPwWgb4lksXsEKs8BTdkgjrAe1J1z4EgKocgpfrQs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=E1ehtmWPNvNVtdnujVIxQXTj0IQ1g6f1m/AKk4hufJP6AK/57LbF7kuzyZ5CvUvDo mOPi72F3KTdrmoLD4DGE6FTMChmY/4fVkoy5fwb1qB1mdCRM2qnlqFs1f4/y88UEKv VkgViM2MJ3ktRDUvmeWEJor4C+xFlHuLOOKLgeVAAeWpG6fq2zDrMN/RapC2+dKVy0 vkQC1etJsAYRP0HrxNM1BZytwpPiNne+yDI4F+konniOZfQ/bJJN4LSnEEPLK+q6w9 /q2oATO79nVoRwRTWNYd7Jh0ShEBF2Qfai6trlJSe5vw3lgiypoqM+7Nu9Bmg6iwFG nlCOPoRjHqW6A== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 21:57:04 -0000 On 10/9/13 4:23 PM, Gonzalo Salgueiro (gsalguei) wrote: > > On Oct 9, 2013, at 2:49 PM, Paul Kyzivat wrote: > >> (as individual) >> >> I agree with Cullen's intent here. >> If others do too, then we just need to agree on the best way to achieve that intent. >> >> If the behavior in this draft is already legal according to RFC3263, then why does it need to be normative? Couldn't it be an informative RFC that describes a more efficient way to use 3263? > > There is likely some level of subjectivity here, but isn't the more efficient way a normative procedure that is a protocol directive with implementation impacts? That strikes me as Standards Track. I don't think "efficient" applies here. Did you mean "effective"? I think the difference between Informational and Standards Track here is that with a standard it becomes possible for someone to claim conformance, and there would be something to test. Also, if there is some question whether the behavior described in this draft is allowed by 3263, then it might be necessary to define this as a revision to 3263. We can talk further about that. I think it comes down to whether the "or" in "A or AAAA" is an *inclusive or" or an *exclusive or*. This is a common ambiguity in English. Does anybody think it was intended as an exclusive or? If it was then you could only use the A records or else the AAAA records - it would be incorrect to use both A and AAAA records in *any* order. If need be we could file an errata to 3263, replacing the "or" with "and/or". There doesn't seem to be an interoperability issue here. This is behavior that is implemented by one party without any need for cooperation by another party. Am I missing something? Thanks, Paul > Gonzalo > >> >> Thanks, >> Paul >> >> >> On 10/9/13 1:45 PM, Dale R. Worley wrote: >>>> From: "Cullen Jennings (fluffy)" >>> >>>> Alternatively, if people make this an update, then you are not 3263 >>>> complaint unless you do this and thus not SIP compliant unless you >>>> do this. I am strongly apposed to that as this is a minor >>>> optimization that does not make much difference in most deployments >>>> (yah yah, your registration when the phone first boots takes 100ms >>>> more - so what). >>> >>> Strictly speaking, even if we make a normative change to 3263, >>> products that do not implement the change are still compliant to >>> *3263*, they're just not compliant to [whatever the new RFC number >>> is]. >>> >>> Indeed, issuing a new RFC, whether or not we called it a "normative >>> change", would simply add another checkbox on the enormously long list >>> of "Does your SIP product implement RFC nnnn?" The customers would >>> place whatever weight they desire on the new checkbox. The only real >>> question seems to be the technical one of whether an implementation >>> can (should?) be fully compliant with the new RFC and also fully >>> compliant with 3263. If not, we need to tag 3263 as having been >>> updated. >>> >>> As to whether the difference is significant in "most deployments", >>> that is something that needs to be investigated. What is the >>> difference in performance likely to be in environments that use IPv6? >>> And certainly, the fraction of environments that are dual stack will >>> be increasing rapidly over the next decade. >>> >>> It does look like the draft has considered how DNS record sets should >>> be constructed to get the best SIP behavior. I worried that that >>> might have been overlooked. (The destination domain is responsible >>> for providing DNS records that obtain good behavior from the sender.) >>> >>> Dale >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From gsalguei@cisco.com Thu Oct 10 16:16:38 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFFE21E817E for ; Thu, 10 Oct 2013 16:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgYYg4elkKf2 for ; Thu, 10 Oct 2013 16:16:34 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C5CF821E8179 for ; Thu, 10 Oct 2013 16:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4792; q=dns/txt; s=iport; t=1381446992; x=1382656592; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=c+QvQDDYqzBvBQwCF+rtSZ1WYEJ6DK3bLUKCLzXpK4g=; b=O0/WpZozj6fAukyfxIZCanPre0Wf3Z/L5lWRA35j3s3RuEpG8qokv7PM tEllRN713IdvN2nhwezu/H13b8tPSd2/06b/hFVKxV/tDi2JxNzp2Dug0 z7VxINvKwBps5RTaRaf8cTdl4sGwiA1xFa30qy4TeeSp3v+TIrqloNe2n Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAFA0V1KtJV2Y/2dsb2JhbABZDoJ5OFLAfkuBIBZ0giUBAQEDAQEBASZFCwULAgECBg4HAwokJwslAgQOBQiHeAYMujIEjxQCMQeDH4EEA4kEiySVX4JlP4Iq X-IronPort-AV: E=Sophos;i="4.90,1075,1371081600"; d="scan'208";a="270710148" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 10 Oct 2013 23:16:32 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9ANGW59014775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 23:16:32 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 10 Oct 2013 18:16:31 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [sipcore] Locating SIP servers in a dual stack IP network Thread-Index: AQHOxRdS7oZT59pTfEykQa0II2UaOZntCjUAgAAaSoCAAaxjgIAAFkOA Importance: high X-Priority: 1 Date: Thu, 10 Oct 2013 23:16:31 +0000 Message-ID: References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> <201310091745.r99HjKH12657849@shell01.TheWorld.com> <5255A53A.1070301@alum.mit.edu> <525722A3.3080902@alum.mit.edu> In-Reply-To: <525722A3.3080902@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.54.162] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <950AA05FADFE43408BD50F9B7DB99E4E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 23:16:38 -0000 On Oct 10, 2013, at 5:56 PM, Paul Kyzivat wrote: > On 10/9/13 4:23 PM, Gonzalo Salgueiro (gsalguei) wrote: >>=20 >> On Oct 9, 2013, at 2:49 PM, Paul Kyzivat wrote: >>=20 >>> (as individual) >>>=20 >>> I agree with Cullen's intent here. >>> If others do too, then we just need to agree on the best way to achieve= that intent. >>>=20 >>> If the behavior in this draft is already legal according to RFC3263, th= en why does it need to be normative? Couldn't it be an informative RFC that= describes a more efficient way to use 3263? >>=20 >> There is likely some level of subjectivity here, but isn't the more effi= cient way a normative procedure that is a protocol directive with implement= ation impacts? That strikes me as Standards Track. >=20 > I don't think "efficient" applies here. Did you mean "effective"? I was simply trying to be contextual by repeating Cullen's exact word; but = sure 'efficient' is likely better. >=20 > I think the difference between Informational and Standards Track here is = that with a standard it becomes possible for someone to claim conformance, = and there would be something to test. It is my understanding that the draft offered something to conform to that = can be tested. >=20 > Also, if there is some question whether the behavior described in this dr= aft is allowed by 3263, then it might be necessary to define this as a revi= sion to 3263. We can talk further about that. >=20 > I think it comes down to whether the "or" in "A or AAAA" is an *inclusive= or" or an *exclusive or*. This is a common ambiguity in English. Does anyb= ody think it was intended as an exclusive or? If it was then you could only= use the A records or else the AAAA records - it would be incorrect to use = both A and AAAA records in *any* order. >=20 > If need be we could file an errata to 3263, replacing the "or" with "and/= or". >=20 > There doesn't seem to be an interoperability issue here. This is behavior= that is implemented by one party without any need for cooperation by anoth= er party. >=20 > Am I missing something? Well obviously I thought 3263 didn't address the issue or we wouldn't have = authored the draft. I'm clearly far too biased, so I leave it to others to= comment on their interpretation of 3263. Cheers, Gonzalo >=20 > Thanks, > Paul >=20 >> Gonzalo >>=20 >>>=20 >>> Thanks, >>> Paul >>>=20 >>>=20 >>> On 10/9/13 1:45 PM, Dale R. Worley wrote: >>>>> From: "Cullen Jennings (fluffy)" >>>>=20 >>>>> Alternatively, if people make this an update, then you are not 3263 >>>>> complaint unless you do this and thus not SIP compliant unless you >>>>> do this. I am strongly apposed to that as this is a minor >>>>> optimization that does not make much difference in most deployments >>>>> (yah yah, your registration when the phone first boots takes 100ms >>>>> more - so what). >>>>=20 >>>> Strictly speaking, even if we make a normative change to 3263, >>>> products that do not implement the change are still compliant to >>>> *3263*, they're just not compliant to [whatever the new RFC number >>>> is]. >>>>=20 >>>> Indeed, issuing a new RFC, whether or not we called it a "normative >>>> change", would simply add another checkbox on the enormously long list >>>> of "Does your SIP product implement RFC nnnn?" The customers would >>>> place whatever weight they desire on the new checkbox. The only real >>>> question seems to be the technical one of whether an implementation >>>> can (should?) be fully compliant with the new RFC and also fully >>>> compliant with 3263. If not, we need to tag 3263 as having been >>>> updated. >>>>=20 >>>> As to whether the difference is significant in "most deployments", >>>> that is something that needs to be investigated. What is the >>>> difference in performance likely to be in environments that use IPv6? >>>> And certainly, the fraction of environments that are dual stack will >>>> be increasing rapidly over the next decade. >>>>=20 >>>> It does look like the draft has considered how DNS record sets should >>>> be constructed to get the best SIP behavior. I worried that that >>>> might have been overlooked. (The destination domain is responsible >>>> for providing DNS records that obtain good behavior from the sender.) >>>>=20 >>>> Dale >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>=20 >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >>=20 >=20 From gsalguei@cisco.com Thu Oct 10 16:18:12 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40DC21E8185 for ; Thu, 10 Oct 2013 16:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GndbhNkwXdZw for ; Thu, 10 Oct 2013 16:18:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id ED32C21E8154 for ; Thu, 10 Oct 2013 16:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5232; q=dns/txt; s=iport; t=1381447087; x=1382656687; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Q7eQhi0KajNvonWvMBtp2ZJkWaAfjPQ98/Ky0OwLlN8=; b=QIpii+0nMS21F1CLZpCopYX1zmh58gWLuQ/02jpWxkc3XfBn8c9AevA2 H0oiCht9pkHPODBkKdOX1ujYfE5QE+RqF8suOvc2VH0Ez9AkKjCGoREiF 8oeYilHnxgafgHeh76hxOYWWAv3VhoYCoQ+vLTdLpW8/K1wP+d/PQ2Kxm 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAD81V1KtJXHB/2dsb2JhbABZDoJ5OFLAfkuBIBZ0giUBAQEDAQEBASYRNAsQAgECBg4HAwoUECcLJQIEDgUIh3gGDLoxBI8UAjEHgx+BBAOUKJVfgmU/gio X-IronPort-AV: E=Sophos;i="4.90,1075,1371081600"; d="scan'208";a="270752386" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 10 Oct 2013 23:18:05 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9ANI57X006656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 23:18:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 10 Oct 2013 18:18:05 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [sipcore] Locating SIP servers in a dual stack IP network Thread-Index: AQHOxRdS7oZT59pTfEykQa0II2UaOZntCjUAgAAaSoCAAaxjgIAAFkOAgAAAbgA= Importance: high X-Priority: 1 Date: Thu, 10 Oct 2013 23:18:04 +0000 Message-ID: References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> <201310091745.r99HjKH12657849@shell01.TheWorld.com> <5255A53A.1070301@alum.mit.edu> <525722A3.3080902@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.54.162] Content-Type: text/plain; charset="us-ascii" Content-ID: <9A904127E235E24FBD0A9732D67CE786@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 23:18:12 -0000 On Oct 10, 2013, at 7:16 PM, "Gonzalo Salgueiro (gsalguei)" wrote: >=20 > On Oct 10, 2013, at 5:56 PM, Paul Kyzivat wrote: >=20 >> On 10/9/13 4:23 PM, Gonzalo Salgueiro (gsalguei) wrote: >>>=20 >>> On Oct 9, 2013, at 2:49 PM, Paul Kyzivat wrote: >>>=20 >>>> (as individual) >>>>=20 >>>> I agree with Cullen's intent here. >>>> If others do too, then we just need to agree on the best way to achiev= e that intent. >>>>=20 >>>> If the behavior in this draft is already legal according to RFC3263, t= hen why does it need to be normative? Couldn't it be an informative RFC tha= t describes a more efficient way to use 3263? >>>=20 >>> There is likely some level of subjectivity here, but isn't the more eff= icient way a normative procedure that is a protocol directive with implemen= tation impacts? That strikes me as Standards Track. >>=20 >> I don't think "efficient" applies here. Did you mean "effective"? >=20 > I was simply trying to be contextual by repeating Cullen's exact word; bu= t sure 'efficient' is likely better. Oops: s/efficient/effective/ Cheers, Gonzalo >>=20 >> I think the difference between Informational and Standards Track here is= that with a standard it becomes possible for someone to claim conformance,= and there would be something to test. >=20 > It is my understanding that the draft offered something to conform to tha= t can be tested. >>=20 >> Also, if there is some question whether the behavior described in this d= raft is allowed by 3263, then it might be necessary to define this as a rev= ision to 3263. We can talk further about that. >>=20 >> I think it comes down to whether the "or" in "A or AAAA" is an *inclusiv= e or" or an *exclusive or*. This is a common ambiguity in English. Does any= body think it was intended as an exclusive or? If it was then you could onl= y use the A records or else the AAAA records - it would be incorrect to use= both A and AAAA records in *any* order. >>=20 >> If need be we could file an errata to 3263, replacing the "or" with "and= /or". >>=20 >> There doesn't seem to be an interoperability issue here. This is behavio= r that is implemented by one party without any need for cooperation by anot= her party. >>=20 >> Am I missing something? >=20 > Well obviously I thought 3263 didn't address the issue or we wouldn't hav= e authored the draft. I'm clearly far too biased, so I leave it to others = to comment on their interpretation of 3263. >=20 > Cheers, >=20 > Gonzalo >=20 >>=20 >> Thanks, >> Paul >>=20 >>> Gonzalo >>>=20 >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>=20 >>>> On 10/9/13 1:45 PM, Dale R. Worley wrote: >>>>>> From: "Cullen Jennings (fluffy)" >>>>>=20 >>>>>> Alternatively, if people make this an update, then you are not 3263 >>>>>> complaint unless you do this and thus not SIP compliant unless you >>>>>> do this. I am strongly apposed to that as this is a minor >>>>>> optimization that does not make much difference in most deployments >>>>>> (yah yah, your registration when the phone first boots takes 100ms >>>>>> more - so what). >>>>>=20 >>>>> Strictly speaking, even if we make a normative change to 3263, >>>>> products that do not implement the change are still compliant to >>>>> *3263*, they're just not compliant to [whatever the new RFC number >>>>> is]. >>>>>=20 >>>>> Indeed, issuing a new RFC, whether or not we called it a "normative >>>>> change", would simply add another checkbox on the enormously long lis= t >>>>> of "Does your SIP product implement RFC nnnn?" The customers would >>>>> place whatever weight they desire on the new checkbox. The only real >>>>> question seems to be the technical one of whether an implementation >>>>> can (should?) be fully compliant with the new RFC and also fully >>>>> compliant with 3263. If not, we need to tag 3263 as having been >>>>> updated. >>>>>=20 >>>>> As to whether the difference is significant in "most deployments", >>>>> that is something that needs to be investigated. What is the >>>>> difference in performance likely to be in environments that use IPv6? >>>>> And certainly, the fraction of environments that are dual stack will >>>>> be increasing rapidly over the next decade. >>>>>=20 >>>>> It does look like the draft has considered how DNS record sets should >>>>> be constructed to get the best SIP behavior. I worried that that >>>>> might have been overlooked. (The destination domain is responsible >>>>> for providing DNS records that obtain good behavior from the sender.) >>>>>=20 >>>>> Dale >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Fri Oct 11 06:45:08 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD2A21E81C4 for ; Fri, 11 Oct 2013 06:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.28 X-Spam-Level: X-Spam-Status: No, score=-0.28 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bN9rx58Huu+V for ; Fri, 11 Oct 2013 06:45:08 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 677E621E81CE for ; Fri, 11 Oct 2013 06:45:01 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta09.westchester.pa.mail.comcast.net with comcast id bno21m0071HzFnQ59pl0Ka; Fri, 11 Oct 2013 13:45:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id bpl01m0063ZTu2S3apl0qG; Fri, 11 Oct 2013 13:45:00 +0000 Message-ID: <525800DB.1010104@alum.mit.edu> Date: Fri, 11 Oct 2013 09:44:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: SIPCORE , CLUE References: <5257A241.7060607@ericsson.com> In-Reply-To: <5257A241.7060607@ericsson.com> X-Forwarded-Message-Id: <5257A241.7060607@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381499100; bh=9nKga5WS+Two+BW2d7jooF+2ak9qqWvHQxu8/n+E7eU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=F6f6IxAGwpGIL6go5OVNQoMDlcBbhBQWzKF8yfYZthgKvxB5p+X/buxwe5cXyXBzS Odg270AY5mWsS8/AEJGv+3nsoJYiBIX8vDc+zW3lkenuyNknOTgtEdOZMRf+LMZWxz +CCI010F0LOxw/JbdMi2lVtjCaL13eWrazavMAma56pOjWTdDv1RBlwnbtySjtgJ6f 3YaU1wUwBTJ3DYICZeWLysH4ielwzGwGEXXzHJirGJgzXO3N9c4Baamr0gvnFRnKE7 CCyee6LwFLUUya0yK4TFWKxQLCy8DDvBM6Hq2LOz/trMzGtSDBv1l5eSV0dOfOwuWE 6ZhU9ooOusxRw== Subject: [sipcore] [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 13:45:08 -0000 People, there is a need for more nominees/volunteers to run for RAI AD, as replacement for Gonzalo, whose term is expiring. If you are interested, or know somebody you would like to run, please speak up. Thanks, Paul -------- Original Message -------- Subject: [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV Date: Fri, 11 Oct 2013 09:44:23 +0300 From: Gonzalo Camarillo To: Folks, we need more volunteers (see email below). If you are thinking of running but still have some doubts about it, feel free to talk with me (or with any of the former RAI ADs) and we will be happy to clarify everything for you. Cheers, Gonzalo -------- Original Message -------- Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV Date: Tue, 8 Oct 2013 11:45:14 -0700 From: NomCom Chair Reply-To: To: IETF Announcement List CC: UPDATE: nominations are too sparse in several of the IESG areas: APP, OAM, RAI, and TSV. If you know one or more of those areas, exercise your social network and submit nominations. We'll be very grateful! Is there someone you work with at IETF who has leadership potential and a growing track record? Please read this Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18. Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. If you're nominated, even if you support the present incumbent, being reviewed by Nomcom is great IETF experience. The questionnaire offers a chance to think about IETF and about your area. Whether or not your candidacy progresses this time, you'll have gained some valuable insights, and you'll have contributed greatly. This process only works because many IETFers take part; please join in. Lots more, including which positions are open, how to make a nomination (including nomination of yourself), and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees! _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai From brett@broadsoft.com Tue Oct 15 04:18:00 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E8F21E80B8 for ; Tue, 15 Oct 2013 04:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdVBn8L2kpDh for ; Tue, 15 Oct 2013 04:17:55 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 39A0211E81CC for ; Tue, 15 Oct 2013 04:17:55 -0700 (PDT) Received: from CASUMHUB05.citservers.local (172.16.98.229) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 15 Oct 2013 04:19:04 -0700 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by casumhub05.citservers.local ([::1]) with mapi id 14.02.0247.003; Tue, 15 Oct 2013 04:19:04 -0700 From: Brett Tate To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Locating SIP servers in a dual stack IP network Thread-Index: AQHOxgPTsTv1M5pqa02ky4tZTq4nGZn1k92A Date: Tue, 15 Oct 2013 11:19:03 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A0639B4@MBX08.citservers.local> References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> <201310091745.r99HjKH12657849@shell01.TheWorld.com> <5255A53A.1070301@alum.mit.edu> <525722A3.3080902@alum.mit.edu> In-Reply-To: <525722A3.3080902@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 11:18:00 -0000 > I think it comes down to whether the "or" in "A or AAAA"=20 > is an *inclusive or" or an *exclusive or*. This is a=20 > common ambiguity in English. Does anybody think it was=20 > intended as an exclusive or?=20 Yes. > If it was then you could only use the A records or else=20 > the AAAA records - it would be incorrect to use both A=20 > and AAAA records in *any* order. RFC 3261 allows "local policy specifying otherwise". However I agree that = RFC 3261 indicates "A or AAAA record lookup of the domain name" instead of = "A and/or AAAA record lookup of the domain name". Thus if an operator pref= ers both A and AAAA to be tried to specific device, they can configure SRV = records accordingly. > There doesn't seem to be an interoperability issue here.=20 > This is behavior that is implemented by one party without=20 > any need for cooperation by another party. It is less about interoperability and more about deployment. The administr= ators need to know how the devices should behave. More specifically, they = need to know if configuring both A and AAAA records corresponding to a spec= ific SRV record's target/device would potentially delay advancement to the = next SRV location/device because of a particular interpretation of RFC 3263= . Thanks, Brett From pkyzivat@alum.mit.edu Tue Oct 15 11:47:02 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6149611E81E0 for ; Tue, 15 Oct 2013 11:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLSmKO0XLWvB for ; Tue, 15 Oct 2013 11:46:56 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 8694211E81A7 for ; Tue, 15 Oct 2013 11:46:54 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta12.westchester.pa.mail.comcast.net with comcast id dQcr1m00116LCl05CWmtsk; Tue, 15 Oct 2013 18:46:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id dWmt1m00U3ZTu2S3SWmtG8; Tue, 15 Oct 2013 18:46:53 +0000 Message-ID: <525D8D9C.1010908@alum.mit.edu> Date: Tue, 15 Oct 2013 14:46:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brett Tate References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> <201310091745.r99HjKH12657849@shell01.TheWorld.com> <5255A53A.1070301@alum.mit.edu> <525722A3.3080902@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B881A0639B4@MBX08.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A0639B4@MBX08.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381862813; bh=o63G/Bjp9PkajIvtlxSja0k2P4CjXLWcw6p91Og7zoU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Mdtr1gR+g3rNgp1v0j1hswTtzjNh1HjfLLnFD+BAhlxFLUMd/tOHo8MGcqaOU15kf mRipijBklkoVg7wF8RPEC/hwcPLfyDFIFsMZ3l6bVetQ5fZr3qRJBJC9a8eES1N/bs JUiGvNrkUPAVEPgFrBN+vttX3dXdtJITmg8JM7P64thzQQGZ1sq4gvYz4xtpqM5Ck1 c8AtbuHd10ASQSTXVTXQDLHlTaQLENd8ybhyPGYtTIvjzYi2vosvBC4f+Dn3DeKidV XlPPhbm36RgU0rwgGYDdecNDPjXAmgpJBdQgAb3dkAxlQjqnGOW0Zuy/ic49fHBkg9 bEhPqWxuMv7QA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 18:47:02 -0000 On 10/15/13 7:19 AM, Brett Tate wrote: >> I think it comes down to whether the "or" in "A or AAAA" >> is an *inclusive or" or an *exclusive or*. This is a >> common ambiguity in English. Does anybody think it was >> intended as an exclusive or? > > Yes. Really! I was thinking it is obviously intended as inclusive OR. >> If it was then you could only use the A records or else >> the AAAA records - it would be incorrect to use both A >> and AAAA records in *any* order. > > RFC 3261 allows "local policy specifying otherwise". However I agree that RFC 3261 indicates "A or AAAA record lookup of the domain name" instead of "A and/or AAAA record lookup of the domain name". Thus if an operator prefers both A and AAAA to be tried to specific device, they can configure SRV records accordingly. > > >> There doesn't seem to be an interoperability issue here. >> This is behavior that is implemented by one party without >> any need for cooperation by another party. > > It is less about interoperability and more about deployment. The administrators need to know how the devices should behave. More specifically, they need to know if configuring both A and AAAA records corresponding to a specific SRV record's target/device would potentially delay advancement to the next SRV location/device because of a particular interpretation of RFC 3263. Good point. But that makes things difficult. If administrators believe "if I configure some AAAA records it might cause my clients to slow down", then it will require widespread adoption of this new proposal before that is fixed and those admins are willing to configure AAAA. Thanks, Paul From worley@shell01.TheWorld.com Wed Oct 16 10:59:28 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFF011E82F3 for ; Wed, 16 Oct 2013 10:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydImvOPiT3yd for ; Wed, 16 Oct 2013 10:59:22 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9C63911E82E1 for ; Wed, 16 Oct 2013 10:59:14 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r9GHwvos026634; Wed, 16 Oct 2013 13:58:59 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r9GHwu9m3089548; Wed, 16 Oct 2013 13:58:56 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r9GHwu3a3079349; Wed, 16 Oct 2013 13:58:56 -0400 (EDT) Date: Wed, 16 Oct 2013 13:58:56 -0400 (EDT) Message-Id: <201310161758.r9GHwu3a3079349@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <525D8D9C.1010908@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> <201310031855.r93Itknq2299577@shell01.TheWorld.com> <007301cec363$7f0bc720$7d235560$@shockey.us> <201310091745.r99HjKH12657849@shell01.TheWorld.com> <5255A53A.1070301@alum.mit.edu> <525722A3.3080902@alum.mit.edu> <576A8B541C219D4E9CEB1DF8C19C7B881A0639B4@MBX08.citservers.local> <525D8D9C.1010908@alum.mit.edu> Cc: sipcore@ietf.org Subject: Re: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 17:59:29 -0000 > From: Paul Kyzivat > > On 10/15/13 7:19 AM, Brett Tate wrote: > >> I think it comes down to whether the "or" in "A or AAAA" > >> is an *inclusive or" or an *exclusive or*. This is a > >> common ambiguity in English. Does anybody think it was > >> intended as an exclusive or? > > > > Yes. > > Really! I was thinking it is obviously intended as inclusive OR. IMO, the trouble is that if one meant to look up the A records as well as the AAAA records (to do queries for two types), one would normally phrase it as "A and AAAA" records. Combining the fact that "A or AAAA" is not the standard way of expressing the "inclusive or" with the fact that "or" is ambiguous in English leads the reader to the possibility that the writer meant "look up the A records exclusive-or look up the AAAA records". > >> There doesn't seem to be an interoperability issue here. > >> This is behavior that is implemented by one party without > >> any need for cooperation by another party. > > > > It is less about interoperability and more about deployment. The > > administrators need to know how the devices should behave. More > > specifically, they need to know if configuring both A and AAAA > > records corresponding to a specific SRV record's target/device > > would potentially delay advancement to the next SRV > > location/device because of a particular interpretation of RFC > > 3263. > > Good point. But that makes things difficult. > > If administrators believe "if I configure some AAAA records it might > cause my clients to slow down", then it will require widespread adoption > of this new proposal before that is fixed and those admins are willing > to configure AAAA. Isn't that ultimately the driver behind the Happy Eyeballs work? The discovery that -- in practice -- adding AAAA records for your web site can slow down some of the clients? It seems to me that we need to determine (1) if there is any risk that current or (under current guidance) future implementations will have undesirable behavior when AAAA records are added, and if so (2) publish new guidance to minimize this undesirable behavior. Both of these depend on how people *interpret* RFCs, and so we have to get to the bottom of current interpretations of 3263, and we have to label any new guidance in a way that maximizes its uptake. Dale From binod.pg@oracle.com Sun Oct 20 21:20:13 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1441211E8147 for ; Sun, 20 Oct 2013 21:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67XT3a8Os+i1 for ; Sun, 20 Oct 2013 21:20:06 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8A611E8132 for ; Sun, 20 Oct 2013 21:20:06 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9L4K4Ko023690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Oct 2013 04:20:05 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9L4K3Ca008764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Oct 2013 04:20:04 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9L4K3Nw018318 for ; Mon, 21 Oct 2013 04:20:03 GMT Received: from [10.178.246.199] (/10.178.246.199) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 20 Oct 2013 21:20:03 -0700 Message-ID: <5264AB70.7000408@oracle.com> Date: Mon, 21 Oct 2013 09:50:00 +0530 From: Binod User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [sipcore] SIP/websocket: SIP Identity question X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 04:20:13 -0000 Hi, Section 7 of sip/websocket says the following. If SIP Digest authentication is not requested for SIP requests coming from the SIP WebSocket Client, then the SIP WebSocket Server MUST authorize SIP requests based on a previous Web or WebSocket login / authentication procedure, and MUST validate that the SIP identity in those SIP requests match the SIP identity associated to the WebSocket connection. I assume, the "SIP identity associated to the WebSocket connection" is not exactly the same as the "web identity" associated with the websocket connection. The RFC draft does not explain how the SIP WebSocket Server maps the "web identity" (example: the username with which user logs into a website) to the "sip identity". So, the "matching" specified in section 7, happens "after" a potential mapping between "web identity" and "sip identity". Did I get it right? Hope draft is not mandating that username with which user logs into the website must match with the sip identity present in the SIP request. thanks, Binod. From internet-drafts@ietf.org Mon Oct 21 15:17:01 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A71F1F0EDF; Mon, 21 Oct 2013 15:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcvcYNQxlVFx; Mon, 21 Oct 2013 15:17:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F15E81F0D5E; Mon, 21 Oct 2013 15:16:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021221653.32508.94706.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:16:53 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-callflows-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:17:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Session Initiation Protocol (SIP) History-Info Header Ca= ll Flow Examples Author(s) : Mary Barnes Francois Audet Shida Schubert Hans Erik van Elburg Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-callflows-07.txt Pages : 47 Date : 2013-10-21 Abstract: This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-callflows-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis-callflows-= 07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pkyzivat@alum.mit.edu Mon Oct 21 15:52:21 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5320C11E87BF for ; Mon, 21 Oct 2013 15:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUSe1ummid8v for ; Mon, 21 Oct 2013 15:52:14 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id F27F811E8798 for ; Mon, 21 Oct 2013 15:52:11 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta03.westchester.pa.mail.comcast.net with comcast id fyZf1m00417dt5G53ysBvo; Mon, 21 Oct 2013 22:52:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id fysB1m00K3ZTu2S3ZysBrs; Mon, 21 Oct 2013 22:52:11 +0000 Message-ID: <5265B019.4070005@alum.mit.edu> Date: Mon, 21 Oct 2013 18:52:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org References: <20131021221653.32508.94706.idtracker@ietfa.amsl.com> In-Reply-To: <20131021221653.32508.94706.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382395931; bh=XEDD6jBcBtzTRSMAIFLdLMUBHUl1myKxOWAYskdbhcE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hxvTMoLTYT/Lk1MjY5X9laP842LeYa7wYxU0nYJlZpWE8+DWsSoK4fNAz8G901Gdz amdWb33gJQDKw+rlBWArsgBm80agsGLxSoRmgOH1h7orqu8YdjpvQAtIl6jE5HOuDN SagcCZiBFMnXdxHhm44jtxbitIVigETvHvGkxLUkzJMnsSHt1itPpnE2odeAfpoxO8 akwxbXUdGITtg8Gs+Hk9DTUvOregr8Wsh+/Uan0nKmD0cTOjLwwCF7Zskw2mgnfoHw ZgG5r9DppnABbW78vWn/Tr0U7eX+hcT2v3Na4Ia/ihswncxoBWV64OTPCoE8VVQ2qH DQUvF51qoejaQ== Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-callflows-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:52:21 -0000 Authors, I note that there is a significantly enhanced example in section 3.2. Did you get a thorough review of this from some competent people? I don't trust myself to do a thorough job. But without looking too hard I can see some problems. Two new messages have been inserted in the middle. That means the old F4,F5,F6 have been renumbered F6,F7,F8. But those changes aren't reflected in the message detail. Thanks, Paul (as co-chair & shepherd) From mary.ietf.barnes@gmail.com Mon Oct 21 16:01:41 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD9F11E87DF for ; Mon, 21 Oct 2013 16:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.38 X-Spam-Level: X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fC-SYQBdqCL1 for ; Mon, 21 Oct 2013 16:01:40 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 18E0311E82C0 for ; Mon, 21 Oct 2013 16:01:06 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id cb5so4745249wib.1 for ; Mon, 21 Oct 2013 16:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DfpxbtSa49g6BUtbBhMbRC8IzWl9qVvAVeDdxoKIFX8=; b=dTx1+VD2V0NRoPUuy2MzVjtnSpizK2IP3pYghxdypnfp/qHGOcQoWPdKkT+mMSLL9B J4QKARxABv4xwMws9vNp6mdKiD4q2s3698ClYABT3PIV17NNGGp4A7D4XoK6/dcjzblJ E5npLcaYFpviwIpG+kY+6mtxX0kwxfru1tKnLTp7OyOG27gFBkhEULpqKfu5InvSl2MK PcoGnHUdpygttu1ZlWFEUMIumhg4PfudCjnvFtSED11JolPMJQMEgS149vYyGG5WuaSE q2DDAlMrJqRcwHMTodCohAaQxwMZFrWJblIVbATlwdkn/s3GWrjj2Ie6y7+IOje3HSX6 RDMQ== MIME-Version: 1.0 X-Received: by 10.180.73.239 with SMTP id o15mr11723535wiv.36.1382396465713; Mon, 21 Oct 2013 16:01:05 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Mon, 21 Oct 2013 16:01:05 -0700 (PDT) In-Reply-To: <5265B019.4070005@alum.mit.edu> References: <20131021221653.32508.94706.idtracker@ietfa.amsl.com> <5265B019.4070005@alum.mit.edu> Date: Mon, 21 Oct 2013 18:01:05 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d0435c00847184d04e94842ec Cc: draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org, SIPCORE Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-callflows-07.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:01:41 -0000 --f46d0435c00847184d04e94842ec Content-Type: text/plain; charset=ISO-8859-1 We made this changed based upon feedback from Stephen Farrell during IESG review (of 4244bis although his comment was explicitly about the call flow document) that the example didn't show anything was privacy protected. You should have seen his comments and my response, since you copied on the email threads. Note, that a variation of this flow was originally taken from RFC 4244 and modified. It was simplified and we lost the idea that was in the flow in RFC 4244 that there would some information that wasn't visible in the response. For the flow in the -06 version there was nothing that wasn't revealed in other messages. So, we updated the example to be closer to the intent of RFC 4244. The authors reviewed, but obviously, since we hadn't submitted the revision no one else has *yet* had the chance to review. We had planned to send a note to the WG mailing list about this change as we clearly recognized it was beyond the scope of nit fixes based on an IESG review. So, if others can also review. You are correct that we failed to update the message numbers in the details, but more importantly we need feedback on the header details. Again, the authors have double-checked, but we won't ask the AD to do anything further with this doc until we have ensured we have addressed the other IESG review comments, as well. Thanks, Mary. On Mon, Oct 21, 2013 at 5:52 PM, Paul Kyzivat wrote: > Authors, > > I note that there is a significantly enhanced example in section 3.2. > Did you get a thorough review of this from some competent people? > > I don't trust myself to do a thorough job. But without looking too hard I > can see some problems. Two new messages have been inserted in the middle. > That means the old F4,F5,F6 have been renumbered F6,F7,F8. But those > changes aren't reflected in the message detail. > > Thanks, > Paul (as co-chair & shepherd) > > --f46d0435c00847184d04e94842ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We made this changed based upon feedback from Stephen Farr= ell during IESG review (of 4244bis although his comment was explicitly abou= t the call flow document) that the example didn't show anything was pri= vacy protected. =A0You should have seen his comments and my response, since= you copied on the email threads.=A0

Note, that a variation of this flow was originally take= n from RFC 4244 and modified. =A0It was simplified and we lost the idea tha= t was in the flow in RFC 4244 that there would some information that wasn&#= 39;t visible in the response. =A0 For the flow in the -06 version there was= nothing that wasn't revealed in other messages. =A0So, we updated the = example to be closer to the intent of RFC 4244. =A0The authors reviewed, bu= t obviously, since we hadn't submitted the revision no one else has *ye= t* had the chance to review. We had planned to send a note to the WG mailin= g list about this change as we clearly recognized it was beyond the scope o= f nit fixes based on an IESG review.=A0

So, if others can also review. =A0 You are correc= t that we failed to update the message numbers in the details, but more imp= ortantly we need feedback on the header details. Again, the authors have do= uble-checked, but we won't ask the AD to do anything further with this = doc until we have ensured we have addressed the other IESG review comments,= as well.=A0

Thanks,
Mary.=A0


On Mon, Oct 21, 2013 at 5:52 P= M, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Authors,

I note that there is a significantly enhanced example in section 3.2.
Did you get a thorough review of this from some competent people?

I don't trust myself to do a thorough job. But without looking too hard= I can see some problems. Two new messages have been inserted in the middle= . That means the old F4,F5,F6 have been renumbered F6,F7,F8. But those chan= ges aren't reflected in the message detail.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul (as co-chair & shepherd)


--f46d0435c00847184d04e94842ec-- From internet-drafts@ietf.org Mon Oct 21 16:52:24 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD0711E8829; Mon, 21 Oct 2013 16:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IfFm4PnywZr; Mon, 21 Oct 2013 16:52:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E337711E82B8; Mon, 21 Oct 2013 16:51:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021235158.32482.76140.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 16:51:58 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-12.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:52:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) fo= r Request History Information Author(s) : Mary Barnes Francois Audet Shida Schubert Detecon International Gmbh Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-12.txt Pages : 36 Date : 2013-10-21 Abstract: This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-rfc4244bis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mary.ietf.barnes@gmail.com Mon Oct 21 16:57:54 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0B311E80DE for ; Mon, 21 Oct 2013 16:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7VIX+trTk3r for ; Mon, 21 Oct 2013 16:57:53 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id BD62111E82B9 for ; Mon, 21 Oct 2013 16:57:50 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w61so7494023wes.10 for ; Mon, 21 Oct 2013 16:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=emujnrkMsppTjFJuLtoLtJDCn5YELXdE7f2vYVS4OYU=; b=aFsWN4QQP9P5ODo/UxUxFgHp9Xz4ZXsjnUhJPpDDaVOgBuQYvG40GRoy913rt3Mluz /pBlGex2n0jnuQmTh6bGXRl4CUFBPsRf2F2N+df4kWVOol9ChrdrxMmmQ84bajDZ2uq0 sKvEzCAJPN+JGEaoW2sDZfPf91q2BxfnMTdabVlH0RQJcexCaZd0OsIq6Vkb8PedokJX nUtQEwwnFOPbMwtWxQc1YWgw8PXz81pup5Y7poFu8ZRsZRydoaRZmChamHeCTSyirFeI lpL4F+m4Co8VhLd6GDwWLGgSYpiHlDIBmoOHzZzgThNTgeSOvx3lDBexDKDDzFKLdJMd mNJg== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr11805261wic.33.1382399869810; Mon, 21 Oct 2013 16:57:49 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Mon, 21 Oct 2013 16:57:49 -0700 (PDT) In-Reply-To: <20131021235158.32482.76140.idtracker@ietfa.amsl.com> References: <20131021235158.32482.76140.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 18:57:49 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: multipart/alternative; boundary=001a11c3844c2d7fe204e9490d36 Cc: Shida Schubert Subject: [sipcore] Fwd: I-D Action: draft-ietf-sipcore-rfc4244bis-12.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:57:55 -0000 --001a11c3844c2d7fe204e9490d36 Content-Type: text/plain; charset=ISO-8859-1 HI all, We have updated the document based on IESG review comments, which you can find here: http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis/ballot/ None of the changes are normative - they are more for clarification and consistency. We will be following up with the SEC AD on the open DISCUSS to see if these changes address his concerns. Regards, Mary. ---------- Forwarded message ---------- From: Date: Mon, Oct 21, 2013 at 6:51 PM Subject: I-D Action: draft-ietf-sipcore-rfc4244bis-12.txt To: i-d-announce@ietf.org Cc: sipcore@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : Mary Barnes Francois Audet Shida Schubert Detecon International Gmbh Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-12.txt Pages : 36 Date : 2013-10-21 Abstract: This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rfc4244bis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a11c3844c2d7fe204e9490d36 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HI all,

We have updated the document ba= sed on IESG review comments, which you can find here:=A0
= http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis/ballot/

None of the changes are normative - they are more= for clarification and consistency. =A0 We will be following up with the SE= C AD on the open DISCUSS to see if these changes address his concerns.=A0

Regards,
Mary.=A0

---------- Forwarded message ----------
= From: <internet-drafts@ietf.org>
Date: Mon, Oct 21, 2013 at 6:51 PM
Subject: I-D Action: draft-ietf-sipco= re-rfc4244bis-12.txt
To: i-d-an= nounce@ietf.org
Cc: sipcore@ietf= .org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Session Initiation Protocol Core Workin= g Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : An Extension to the Session Ini= tiation Protocol (SIP) for Request History Information
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Mary Barnes
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Francois Audet
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Shida Schubert
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Detecon International G= mbh
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Christer Holmberg
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-sipcore-rfc4244bis-12.= txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 36
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-10-21

Abstract:
=A0 =A0This document defines a standard mechanism for capturing the history=
=A0 =A0information associated with a Session Initiation Protocol (SIP)
=A0 =A0request. =A0This capability enables many enhanced services by provid= ing
=A0 =A0the information as to how and why a SIP request arrives at a specifi= c
=A0 =A0application or user. =A0This document defines an optional SIP header=
=A0 =A0field, History-Info, for capturing the history information in
=A0 =A0requests. =A0The document also defines SIP header field parameters f= or
=A0 =A0the History-Info and Contact header fields to tag the method by whic= h
=A0 =A0the target of a request is determined. =A0In addition, this
=A0 =A0specification defines a value for the Privacy header field that
=A0 =A0directs the anonymization of values in the History-Info header field= .
=A0 =A0This document obsoletes RFC 4244.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc42= 44bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis-12<= /a>

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcor= e-rfc4244bis-12


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--001a11c3844c2d7fe204e9490d36-- From brett@broadsoft.com Tue Oct 22 04:49:11 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF3B11E8367 for ; Tue, 22 Oct 2013 04:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuYee-eJlhKS for ; Tue, 22 Oct 2013 04:49:06 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 94F8F11E818C for ; Tue, 22 Oct 2013 04:49:04 -0700 (PDT) Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 22 Oct 2013 04:50:19 -0700 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Tue, 22 Oct 2013 04:50:19 -0700 From: Brett Tate To: "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" , "sipcore@ietf.org" Thread-Topic: draft-ietf-sipcore-rfc4244bis-callflows-07: comments Thread-Index: Ac7PHLMp/5Tu/0FgRGCvRlFZ3y2XTA== Date: Tue, 22 Oct 2013 11:50:18 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A065A5E@MBX08.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-07: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 11:49:11 -0000 Hi, The following are a few comments concerning draft-ietf-sipcore-rfc4244bis-c= allflows-07. Thanks, Brett ------- Global comment: "Max-Forward:" should be "Max-Forwards:". Section 3.2: 1) Figure 2: If not intentional, the ACK for the 302 is not shown. 2) F4: The Max-Forward (assuming Max-Forwards) should not be within the res= ponse. 3) F4: To tag should be added for RFC 3261 compliance. 4) The F numbering should match the Figure 2. 5) Second F5: Based upon second F4, the "received=3D192.0.2.101" should be = "received=3D192.0.2.3". This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it. From mary.ietf.barnes@gmail.com Tue Oct 22 06:13:48 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD5111E8378 for ; Tue, 22 Oct 2013 06:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb9dEY2Q-TO7 for ; Tue, 22 Oct 2013 06:13:48 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6F46311E846A for ; Tue, 22 Oct 2013 06:13:43 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q58so8155432wes.31 for ; Tue, 22 Oct 2013 06:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QozJtkqY2WOZ+W4/BjAutApVmnuPwF35Z+6mzKBahog=; b=YTt/Etgm3/6+QcEeBnnrFaYUKvO0vH3e/3cU+aY3aMUOP838jUbXTCP759SpGWPuU/ 0rR5ONpr4PPK5C/KRtKeZf41LO9je/BH4OsIV42RI8PPChmYT2o+ZRJKe0TVQVB/1HFv i0IvQg7nHwIGKbamgC2Pll3n3IdOKJ0NnT7s4lHQMR0QUDTYmr/ePij8846/Bu+jY4H/ O9LmmvPMqQuEoB/NT0+CJ2XNHGTh+/aXcNDvhVB7JrRNyEjdXm8fPAjVcaAGmQ+FfGoQ 7tuopN+R7MtRe6niXMY+F8gk2bkv/KTYeqFXlI4uDqIczSVxVYQntnk4aio8mL4mZKtw 3gwQ== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr14385010wic.33.1382447622507; Tue, 22 Oct 2013 06:13:42 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Tue, 22 Oct 2013 06:13:42 -0700 (PDT) In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A065A5E@MBX08.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B881A065A5E@MBX08.citservers.local> Date: Tue, 22 Oct 2013 08:13:42 -0500 Message-ID: From: Mary Barnes To: Brett Tate Content-Type: multipart/alternative; boundary=001a11c3844c75d0c704e9542b15 Cc: "draft-ietf-sipcore-rfc4244bis-callflows@tools.ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-07: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 13:13:48 -0000 --001a11c3844c75d0c704e9542b15 Content-Type: text/plain; charset=ISO-8859-1 Brett, Thanks very much for your careful review. We will fix those errors and have an update ready to go when the submission window re-opens in a couple weeks. Thanks, Mary. On Tue, Oct 22, 2013 at 6:50 AM, Brett Tate wrote: > Hi, > > The following are a few comments concerning > draft-ietf-sipcore-rfc4244bis-callflows-07. > > Thanks, > Brett > > ------- > > Global comment: "Max-Forward:" should be "Max-Forwards:". > > Section 3.2: > > 1) Figure 2: If not intentional, the ACK for the 302 is not shown. > > 2) F4: The Max-Forward (assuming Max-Forwards) should not be within the > response. > > 3) F4: To tag should be added for RFC 3261 compliance. > > 4) The F numbering should match the Figure 2. > > 5) Second F5: Based upon second F4, the "received=192.0.2.101" should be > "received=192.0.2.3". > > This email is intended solely for the person or entity to which it is > addressed and may contain confidential and/or privileged information. If > you are not the intended recipient and have received this email in error, > please notify BroadSoft, Inc. immediately by replying to this message, and > destroy all copies of this message, along with any attachment, prior to > reading, distributing or copying it. > --001a11c3844c75d0c704e9542b15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Brett,

Thanks very much for your = careful review. =A0We will fix those errors and have an update ready to go = when the submission window re-opens in a couple weeks.

=
Thanks,
Mary.=A0


On Tue, Oct 22, 2013 at 6:50 AM, = Brett Tate <brett@broadsoft.com> wrote:
Hi,

The following are a few comments concerning draft-ietf-sipcore-rfc4244bis-c= allflows-07.

Thanks,
Brett

-------

Global comment: =A0"Max-Forward:" should be "Max-Forwards:&q= uot;.

Section 3.2:

1) Figure 2: If not intentional, the ACK for the 302 is not shown.

2) F4: The Max-Forward (assuming Max-Forwards) should not be within the res= ponse.

3) F4: To tag should be added for RFC 3261 compliance.

4) The F numbering should match the Figure 2.

5) Second F5: Based upon second F4, the "received=3D192.0.2.101" = should be "received=3D192.0.2.3".

This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it.

--001a11c3844c75d0c704e9542b15-- From adam@nostrum.com Tue Oct 22 14:07:16 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A7711E820E for ; Tue, 22 Oct 2013 14:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kr0+k1xrMbz for ; Tue, 22 Oct 2013 14:07:16 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DB9F811E81FF for ; Tue, 22 Oct 2013 14:07:11 -0700 (PDT) Received: from orochi.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r9ML6xNx059028 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Oct 2013 16:07:01 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5266E8EE.5060609@nostrum.com> Date: Tue, 22 Oct 2013 16:06:54 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "'SIPCORE'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: dispatch-chairs@tools.ietf.org, SIPCORE Chairs , draft-johansson-sip-dual-stack@tools.ietf.org, "rai-ads@tools.ietf.org" Subject: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 21:07:16 -0000 [as chair] It has been brought to our attention that there might be some confusion about the status of and venue for discussing the draft-johansson-sip-dual-stack document. The SIPCORE chairs, together with our Area Director and the DISPATCH chairs, have determined that the proper working group for this work, if it proceeds, is SIPCORE. That said, we have not yet heard enough from the community to yet determine whether to add a deliverable to the SIPCORE charter for IPv4/IPv6 interactions. So, the first step here is to determine whether there's enough interest to add a milestone for updating or clarifying RFC 3263 procedures when both A and AAAA records exist for a single authority. To be clear, we're deferring a discussion of adopting the johansson draft until after we have gauged interest around doing this kind of work in the first place. However, interested parties should continue to discuss that draft on the SIPCORE mailing list. If you are interested in SIPCORE taking on a milestone to perform this work, please respond on-list with a short message indicating your interest, and whether you would be willing to actively participate in the associated conversations and document reviews. Thanks! /a From rifaat.ietf@gmail.com Wed Oct 23 06:29:17 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E8411E8196 for ; Wed, 23 Oct 2013 06:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAiXwdPIIpOv for ; Wed, 23 Oct 2013 06:29:17 -0700 (PDT) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF9921F8531 for ; Wed, 23 Oct 2013 06:29:11 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id d49so403129eek.14 for ; Wed, 23 Oct 2013 06:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dpFLX8wWDXXKBfpzPGEwwOdk8COar8bq+yzSsxnKGV4=; b=0hGv7eMWMNmcVp7l43OtVHe4OIkzm0PVPTX44M8kwRTYzwwRlALEu3sJ8p8nG1Ve/O UABIZ8M2JWviVcktsON8gEhij43T+bBdKi/ArXVND5Csx2x5vXtjsy0fWNQ3B0z9hArJ MyjWCfjM8WtHSz4EQyiiwJwFQIFtc03NMYKEUp7svbOFwBfW8nTGPEt23CM9qxZmH59E T2dsvmOrnhgMNqeOdTz0JWChhGe/uCdovGCjFLwgzXLdeeybgyt1x8Sba5xKRYoZUdfK 9SvNTyovLCOIrEPe2AO2CMmpVncU84t6NPVckR+dGM7Y1UEY1BqZquZAtMuwAyMxqM4B D18Q== MIME-Version: 1.0 X-Received: by 10.14.184.132 with SMTP id s4mr1832396eem.13.1382534950574; Wed, 23 Oct 2013 06:29:10 -0700 (PDT) Received: by 10.14.144.145 with HTTP; Wed, 23 Oct 2013 06:29:10 -0700 (PDT) In-Reply-To: <5266E8EE.5060609@nostrum.com> References: <5266E8EE.5060609@nostrum.com> Date: Wed, 23 Oct 2013 09:29:10 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Adam Roach Content-Type: multipart/alternative; boundary=047d7b3438f69e600a04e968801d Cc: dispatch-chairs@tools.ietf.org, "rai-ads@tools.ietf.org" , draft-johansson-sip-dual-stack@tools.ietf.org, SIPCORE , SIPCORE Chairs Subject: Re: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 13:29:18 -0000 --047d7b3438f69e600a04e968801d Content-Type: text/plain; charset=ISO-8859-1 Adam, Some pf us have already expressed support for this work; are you asking us to do that again? If so, then I support this work and would be ready to review and contribute to this effort. Regards, Rifaat On Tue, Oct 22, 2013 at 5:06 PM, Adam Roach wrote: > [as chair] > > It has been brought to our attention that there might be some confusion > about the status of and venue for discussing the > draft-johansson-sip-dual-stack document. > > The SIPCORE chairs, together with our Area Director and the DISPATCH > chairs, have determined that the proper working group for this work, if it > proceeds, is SIPCORE. That said, we have not yet heard enough from the > community to yet determine whether to add a deliverable to the SIPCORE > charter for IPv4/IPv6 interactions. > > So, the first step here is to determine whether there's enough interest to > add a milestone for updating or clarifying RFC 3263 procedures when both A > and AAAA records exist for a single authority. > > To be clear, we're deferring a discussion of adopting the johansson draft > until after we have gauged interest around doing this kind of work in the > first place. However, interested parties should continue to discuss that > draft on the SIPCORE mailing list. > > If you are interested in SIPCORE taking on a milestone to perform this > work, please respond on-list with a short message indicating your interest, > and whether you would be willing to actively participate in the associated > conversations and document reviews. > > Thanks! > > /a > ______________________________**_________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/**listinfo/sipcore > --047d7b3438f69e600a04e968801d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adam,

Some pf us have already expressed= support for this work; are you asking us to do that again?
If so= , then I support this work and would be ready to review and contribute to t= his effort.

Regards,
=A0Rifaat

<= br>


On Tue, Oct 22, 2013 at 5:06 PM, Adam Roach <adam@nostrum.com> wrote:
[as chair]

It has been brought to our attention that there might be some confusion abo= ut the status of and venue for discussing the draft-johansson-sip-dual-stac= k document.

The SIPCORE chairs, together with our Area Director and the DISPATCH chairs= , have determined that the proper working group for this work, if it procee= ds, is SIPCORE. That said, we have not yet heard enough from the community = to yet determine whether to add a deliverable to the SIPCORE charter for IP= v4/IPv6 interactions.

So, the first step here is to determine whether there's enough interest= to add a milestone for updating or clarifying RFC 3263 procedures when bot= h A and AAAA records exist for a single authority.

To be clear, we're deferring a discussion of adopting the johansson dra= ft until after we have gauged interest around doing this kind of work in th= e first place. However, interested parties should continue to discuss that = draft on the SIPCORE mailing list.

If you are interested in SIPCORE taking on a milestone to perform this work= , please respond on-list with a short message indicating your interest, and= whether you would be willing to actively participate in the associated con= versations and document reviews.

Thanks!

/a
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--047d7b3438f69e600a04e968801d-- From oej@edvina.net Wed Oct 23 12:36:46 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3498811E836F for ; Wed, 23 Oct 2013 12:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ex8fQOfUjEjd for ; Wed, 23 Oct 2013 12:36:45 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4743B11E820A for ; Wed, 23 Oct 2013 12:36:39 -0700 (PDT) Received: from [192.168.1.66] (unknown [189.188.166.41]) by smtp7.webway.se (Postfix) with ESMTPA id D3FAE93C2A2; Wed, 23 Oct 2013 19:36:14 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_5977C3EE-E176-445F-97BE-963043E74F46"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "Olle E. Johansson" In-Reply-To: <5266E8EE.5060609@nostrum.com> Date: Wed, 23 Oct 2013 21:36:33 +0200 Message-Id: <4F379740-43E9-4AF0-B80A-CA769F3B94C0@edvina.net> References: <5266E8EE.5060609@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1510) Cc: SIPCORE Chairs , dispatch-chairs@tools.ietf.org, 'SIPCORE' , "Olle E. Johansson" , "rai-ads@tools.ietf.org" , draft-johansson-sip-dual-stack@tools.ietf.org Subject: Re: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:36:46 -0000 --Apple-Mail=_5977C3EE-E176-445F-97BE-963043E74F46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 22 okt 2013 kl. 23:06 skrev Adam Roach : > [as chair] >=20 > It has been brought to our attention that there might be some = confusion about the status of and venue for discussing the = draft-johansson-sip-dual-stack document. >=20 > The SIPCORE chairs, together with our Area Director and the DISPATCH = chairs, have determined that the proper working group for this work, if = it proceeds, is SIPCORE. That said, we have not yet heard enough from = the community to yet determine whether to add a deliverable to the = SIPCORE charter for IPv4/IPv6 interactions. >=20 > So, the first step here is to determine whether there's enough = interest to add a milestone for updating or clarifying RFC 3263 = procedures when both A and AAAA records exist for a single authority. >=20 > To be clear, we're deferring a discussion of adopting the johansson = draft until after we have gauged interest around doing this kind of work = in the first place. However, interested parties should continue to = discuss that draft on the SIPCORE mailing list. >=20 > If you are interested in SIPCORE taking on a milestone to perform this = work, please respond on-list with a short message indicating your = interest, and whether you would be willing to actively participate in = the associated conversations and document reviews. >=20 > Thanks! Personally I think it's the duty of the IETF to make sure that the = transition to IPv6 works smoothly. Without work on dual stack, the SIP = vendors will not dare delivering dual stack solutions and we'll stay on = IPv4-only VPNs.=20 We have proven that there are a lot of issues with dual stack networks = at SIPit tests. So my answer is yes, SIPcore needs to work on this in my opinion. /O= --Apple-Mail=_5977C3EE-E176-445F-97BE-963043E74F46 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCBdEw ggO5oAMCAQICAwzF9zANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMzAxMjYxMjM0MjlaFw0x NTAxMjYxMjM0MjlaMHExFzAVBgNVBAMTDk9sbGUgSm9oYW5zc29uMR0wGwYJKoZIhvcNAQkBFg5v ZWpAZWR2aW5hLm5ldDE3MDUGCSqGSIb3DQEJARYoMDc2ZGY1NDBkZGJiMmJkNTliNTUxYTRjZWY5 MjE4NmQzNjNkYmIyNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmqasMHgkaLk5k0 wLfHa8L3ICewso+Sf8NWodzRroWD3GGT94T70v5qTYlXMs7K3H0kFGvKmk4JGPa+TbDptfcjicqY 9PGGB9ILQQ02jP8lvm1QJuDKrXoZ70C5ApW8dy4fjVmy4iDWugDeEYXRzvuSS3H7ygFzPFAOX80q r2pUzn/uRw4ui7EPp0g3nv1wfpVQ65zKYiy28Xzuvut8S3o9BsWPq9zCzfes2jJrKoMnyKDodmBD 3QZaCxPplmLKoW/7QylznhdI5H1xBWoMRvUAvdxY7bucwcDzChxGXzhrbtov2qz/CHV4UqBxdLmJ 4absg9wIk09IaWgThoe3d5MCAwEAAaOCAWgwggFkMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgEN BEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0 cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNVHSUEOTA3BggrBgEFBQcDBAYI KwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQm MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMQYDVR0fBCowKDAmoCSgIoYg aHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwQwYDVR0RBDwwOoEOb2VqQGVkdmluYS5u ZXSBKDA3NmRmNTQwZGRiYjJiZDU5YjU1MWE0Y2VmOTIxODZkMzYzZGJiMjUwDQYJKoZIhvcNAQEF BQADggIBACp/GHgzobsgkZc2IHN7cZO/WF75ykiH+DMS7MkOXqjZCYBsyNT++TZ1n9Fs8fO75c0b UD5Yr4uM8j8z/1JzASqYMNZhmCAsAHvbyEEOJhtjBJhmSFUI+k1UWcK5SQ+FBsgF/RN39RTOKNaP sr3pUVRF0aC9DxmPgx4Duv5k7IMPEJKcBmTd2775/MPJRwQqyCIlaBPHlIjxG1yM+Z0hBIXYBW4F +s9GbYsIuvd5MqgM2Vkak1hqBkV7+jkb3EOC0L1sA8ZpjszUbeX0bwojTBx1nA79+ijtKN98gH4y EcLWbgW9b6OX//LltaXNBCGVv66OCLE5zwsOhSkjq1S8oHwBc+li3cSIfwYwYbWGBb2fUfKtPOT1 1fuBz+V2v2pChCDLF8e0LnY2i9SfuQxWtpgDXlR2+1GiXjM3BozlWtP1ske+II470nDziiPx2AYF aVKFwfaCcGT/eVHnNVgvYYDcL5n5oiP3ZvORsrnQQOZfzQ9m0A6cZMkB7eQ3muODPp6S3ghR6Ghb +qSB2PdjvQXg/nkZeVd4vlIpXK0gC0hdnG/+jkj3Dvepf1Bqodh5XqgbBgP4n8yeyPyuj+sXCaGU szESHQw+s8Xgy4/xnBL0PG7a7WeJ9J5Py4udrDP/cp2mNsjX5Gp4UvCdJ5ciMwqxwwcHgIbTJDyn 1kz/dIKyMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJ KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwzF9zAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzEwMjMxOTM2MzRaMCMGCSqGSIb3 DQEJBDEWBBSnG7Kw9hU8I/OY8KJ4h30JZP3iVTCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn AgMMxfcwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMxfcwDQYJKoZIhvcNAQEBBQAE ggEAJkJOuvb9irq3DExCvtSMjbvz55GOmIbQ5SUVoAKAnN9cka5N5wYluzvH8dNiCVCdRvIxIYy1 Q303uVW9dzXdWZYJtIEee7NwsRoQ/9vzMZRMiUNx6+VULRHpdfohfZQwZ4GxSC6ccGT12H6fJUfV H2sLmd7Nv4QFhkZz3V5/QO2H0/ac57iajqWvfN5fyqxAg4kgZSOI20Y460seWh0yC8cM/HeZGwY6 ZnWl5cca0JBUxQ6QsmyuByde/Yqu8cGQms+9dYVKYjYb2uEgQ5ufy5KzC7YHBEiPIGuM2uiURjBD VnHoQkzQ7lvrb5O5tQislJ0qYYOrp+aPB/U4+LsrGwAAAAAAAA== --Apple-Mail=_5977C3EE-E176-445F-97BE-963043E74F46-- From pkyzivat@alum.mit.edu Wed Oct 23 13:17:04 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A3911E820C for ; Wed, 23 Oct 2013 13:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.297 X-Spam-Level: X-Spam-Status: No, score=-0.297 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KDt9+kS0d+X for ; Wed, 23 Oct 2013 13:16:58 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id E5DDB11E81BC for ; Wed, 23 Oct 2013 13:16:57 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA11.westchester.pa.mail.comcast.net with comcast id ggha1m00x16LCl05BkGws9; Wed, 23 Oct 2013 20:16:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id gkGw1m00H3ZTu2S3SkGwQ5; Wed, 23 Oct 2013 20:16:56 +0000 Message-ID: <52682EB8.2030502@alum.mit.edu> Date: Wed, 23 Oct 2013 16:16:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <5266E8EE.5060609@nostrum.com> <4F379740-43E9-4AF0-B80A-CA769F3B94C0@edvina.net> In-Reply-To: <4F379740-43E9-4AF0-B80A-CA769F3B94C0@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382559416; bh=stBdNM5MJC2mtXhc0snUpvLctBzPGbzxqACZ0CiUTCo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pqgCRePlkoyAeoIJOgSVFC2Ami6byvM5ebdWm56r+w/djnuTmtFezj+9jBMq1STaF gQ4ElYfJpeNu0OhksyymOeURbpC0CSCsWO0FIPnfbB57iewkAfXR+iOamSdRGDxjwd VH3jxsDvXhHqKyVn25StUkOULWnuxFEH9LKGbP+Ab9TG0QPNSpFkthtM0yoSpfO+0s bDFUXkiOtA1hlOU6JkLEHHG/4cm8NWr+6Ir0UpvgERjgGmq3DPxPB2EHiJSiSAeSC0 Z0YrCdvrsANwFlCwdyqQVrkm4qFtfTgj5noZJUCU/eAepjOpw6k8OSJ5CMLEEzxZCO uNiaBCeJp/Z/g== Subject: Re: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 20:17:04 -0000 On 10/23/13 3:36 PM, Olle E. Johansson wrote: > Personally I think it's the duty of the IETF to make sure that the transition to IPv6 works smoothly. Without work on dual stack, the SIP vendors will not dare delivering dual stack solutions and we'll stay on IPv4-only VPNs. > We have proven that there are a lot of issues with dual stack networks at SIPit tests. I think so too. But the only resources the IETF has to work on this are the ones reading this mail. What we need to know is if there is a sufficient body of people willing, and sufficiently knowledgeable, to *contribute*. Minimally by reviewing and commenting on drafts. But we need people who will do more - provide text, implement, test. So we are looking for people who will promise to do those things. Thanks, Paul From ietf-lists@kerker.se Thu Oct 24 00:51:54 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36CF11E80F9 for ; Thu, 24 Oct 2013 00:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT3-CWspKWBc for ; Thu, 24 Oct 2013 00:51:54 -0700 (PDT) Received: from mail.kerker.se (arthur.kerker.se [IPv6:2a01:7900:40:11::2]) by ietfa.amsl.com (Postfix) with ESMTP id B0C0C11E815C for ; Thu, 24 Oct 2013 00:51:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.kerker.se (Postfix) with ESMTP id 59520DA25A2 for ; Thu, 24 Oct 2013 09:51:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kerker.se; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1382601063; x=1385193064; bh=dvpEIFwxyld5+XA7SK3p6YvxABqDNEOmVv9 PN5AGo7E=; b=OWqzDm4dY/htgRpAmcNEjCm9AUbg4EL8Q/CD/H4gzDSSNZKNmf6 ga6cojGAwAYh+iTrLxn2QgUysDeVw9O+np+9avVwQnJ4sQhDJtP6a4kiOyvJepuH /opFn6xcfCM5FXieEJJkzBdbcn2xCqaaHI6T/O8oii1UDJKSTPRpq4k0= X-Virus-Scanned: amavisd-new at kerker.se Received: from mail.kerker.se ([127.0.0.1]) by localhost (arthur.kerker.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGL3HGFIIDfK for ; Thu, 24 Oct 2013 09:51:03 +0200 (CEST) Received: from [172.16.3.8] (user60.217-10-108.netatonce.net [217.10.108.60]) by mail.kerker.se (Postfix) with ESMTPSA id AB5E6DA258A for ; Thu, 24 Oct 2013 09:51:03 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Staffan Kerker In-Reply-To: <52682EB8.2030502@alum.mit.edu> Date: Thu, 24 Oct 2013 09:51:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49EE55E9-27B7-45AA-8395-C3F1A23FF774@kerker.se> References: <5266E8EE.5060609@nostrum.com> <4F379740-43E9-4AF0-B80A-CA769F3B94C0@edvina.net> <52682EB8.2030502@alum.mit.edu> To: sipcore@ietf.org X-Mailer: Apple Mail (2.1816) Subject: Re: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 07:51:54 -0000 On 23 okt 2013, at 22:16, Paul Kyzivat wrote: > So we are looking for people who will promise to do those things. I=92m happy to review, comment and contribute where possible to this = work. //Staffan -- Staffan Kerker mail/sip/xmpp: staffan@kerker.se "There is absolutely no money above the 5th fret..." /Donald "Duck" Dunn From pkyzivat@alum.mit.edu Thu Oct 24 10:36:41 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8F011E835C for ; Thu, 24 Oct 2013 10:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mC+PotoVSLk6 for ; Thu, 24 Oct 2013 10:36:20 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 2707711E81B9 for ; Thu, 24 Oct 2013 10:36:04 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta01.westchester.pa.mail.comcast.net with comcast id gzxY1m0061HzFnQ515bv3s; Thu, 24 Oct 2013 17:35:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id h5bv1m00h3ZTu2S3a5bvVK; Thu, 24 Oct 2013 17:35:55 +0000 Message-ID: <52695A7B.8010207@alum.mit.edu> Date: Thu, 24 Oct 2013 13:35:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Andrew Allen References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382636155; bh=e29/2OAl0TiEEUu6sGeG5AEkSMkgk6JfC5qqr3n1MyI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fSej8q2AMpZiI1Sh2RSz7VQ/6dS/HyEvBbMLznGs64Uu6I1n5Jy8GUgMESCisyquO lAo/8E8LppqZk0RMVoj6DPsDPixGiU4KGRFfBGa1S/EUbOGLDiTmce6hQos/rgQjdH NppdPqsnMEZzbk6DX2GXvtTwKKfrtd+otpP0LaemrfvUzwnUGMJlFiaiZwVU24IXe8 utMTwA90ZZL1sL4ylrnMKYLKA5/8kuGA4EMfh4yJzbzyjW+hw93xukI4vCKz9hv6BC ACeHTdDMEt1vk0lI3M9PHlbGHW6xDVe6acfMzEr0IqVXkWnzhFiU5EmNbUwjXmdEli +inyw7uaWAzzA== Cc: SIPCORE Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 17:36:41 -0000 Andrew, This draft troubles me. It takes feature-caps in exactly the direction that I found most concerning about that mechanism in the first place. The draft partitions the existing media feature tags into two sets - those that would be useful as feature-capability-indicators, and those that aren't. But I see no explanation of the criteria used to make this distinction, nor can I think of one. For the ones that you have requested feature capability indicators, I cannot figure out what using them would mean. For example, when I see isFocus on a Contact header I know I am in a conference, and that I can subscribe to the conference event package at the contact URI. If I see isFocus in a Feature-Caps header, what does it mean? What can I do once I know this? Section 5.14 of this draft says: This Feature-capability indicator indicates that the intermediary is a conference server, also known as a focus, and is capable of mixing together the media for all calls to the same URI. ... Examples of typical use: A conference bridge indicating that it is a conference bridge and is capable of acting as a conference focus for this session. Note that Feature-Caps doesn't indicate which entity has this capability, only that something does. And since this would presumably only be used if it wasn't the UAC of the request, sending a subscribe to the contact address of the UAC wouldn't make sense. If there is a conference bridge in the signaling path, then I would expect it to be the UAC. As another example, consider section 5.1: Descrition: This Feature-capability indicator indicates that the intermediary supports audio as a streaming media type. ... Examples of typical use: An IP PBX indicating that it is capable of accepting and initiating sessions with audio as a streaming media type. This definition *implies* an assumption about the working environment - one that AFAIK is new. It implies that you need to know that intermediaries support a media type before you can use it. Would it be bad if there were no intermediaries, and so none indicated this? What if some intermediary *did* indicate support, but some other doesn't, but doesn't indicate that it doesn't? Bottom line: how would the presence or absence of this feature tag affect subsequent usage? I could go on, but this is enough for now. Thanks, Paul On 10/22/13 3:44 AM, Andrew Allen wrote: > Adam, Paul, Richard, Gonzalo > > I have submitted a new draft to sipcore to register a number of feature > capability indicators in the SIP tree (based upon some of the existing > SIP media feature tags). The draft can be found at: > > http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00.txt > > Since there will not be a sipcore session at IETF#88 can we have an > offline discussion on how to progress this draft (which hopefully is > fairly straightforward as it just registers feature capabilities > indicators with IANA). I wouldn’t want to have to wait until March next > year for a decision on progressing this. > > Andrew > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and delete > this information from your system. Use, dissemination, distribution, or > reproduction of this transmission by unintended recipients is not > authorized and may be unlawful. From aallen@blackberry.com Thu Oct 24 11:15:03 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFD521E80A8 for ; Thu, 24 Oct 2013 11:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7b+Oa6YO3dqR for ; Thu, 24 Oct 2013 11:14:58 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA3221E8096 for ; Thu, 24 Oct 2013 11:14:54 -0700 (PDT) Received: from xct104ads.rim.net ([10.67.111.45]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 24 Oct 2013 14:14:52 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.03.0123.003; Thu, 24 Oct 2013 13:14:51 -0500 From: Andrew Allen To: Paul Kyzivat Thread-Topic: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: Ac7O86axXV4mf2iKTCu4hnOiGnoZFACFcAeAAAlumjA= Date: Thu, 24 Oct 2013 18:14:51 +0000 Message-ID: References: <52695A7B.8010207@alum.mit.edu> In-Reply-To: <52695A7B.8010207@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: SIPCORE Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 18:15:03 -0000 Paul Thanks for reviewing the draft already and giving me early feedback. My responses below inline (prepended with [AA). Andrew -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] = Sent: Thursday, October 24, 2013 1:36 PM To: Andrew Allen Cc: SIPCORE Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-= indicators Andrew, This draft troubles me. It takes feature-caps in exactly the direction that= I found most concerning about that mechanism in the first place. The draft partitions the existing media feature tags into two sets - those = that would be useful as feature-capability-indicators, and those that aren'= t. But I see no explanation of the criteria used to make this distinction, = nor can I think of one. [AA] I based this decision on the following criteria: If a feature tag was = potentially at all useful for an intermediary to indicate it then include i= t in the registry. The ones not included are either directly associated wit= h the user (intermediaries are not directly associated with the user) or w= ould only ever have one value (e.g automata). I am not sure that every fea= ture-capability indicator proposed to be registered is actually useful but = then I don't think every media feature tag registered by RFC 3840 is either= (I doubt very much if there are implementation using the sip.application o= r sip.control feature tags). I don't think RFC 3840 goes into a lot of deta= ils justifying every registered media feature tag and specifying the detail= s of how they would be used either. I am willing to remove any feature-cap= ability indicators that are really controversial except that I think we def= initely need sip.extensions, sip.methods and sip.events. There is a signifi= cant overhead to writing and progressing internet drafts so my view is lets= register all that might be remotely useful in the same document (provided = they don't become rat holes!). For the ones that you have requested feature capability indicators, I canno= t figure out what using them would mean. For example, when I see isFocus on= a Contact header I know I am in a conference, and that I can subscribe to = the conference event package at the contact URI. If I see isFocus in a Feat= ure-Caps header, what does it mean? What can I do once I know this? Section 5.14 of this draft says: This Feature-capability indicator indicates that the intermediary is a conference server, also known as a focus, and is capable of mixing together the media for all calls to the same URI. ... Examples of typical use: A conference bridge indicating that it is a conference bridge and is capable of acting as a conference focus for this session. [AA] the presence of isfocus in a Feature-Caps header field means that a UA= can initiate a conference by sending a REFER request to the intermediary t= o invite another user and create a multi user conference from the 1-1 sessi= on. I don't think this is really much different semantically than the situa= tion of a 3 party call after a participant leaves. The focus is the place I= send requests to add participants and where I subscribe to the conference = event package - in this the semantic is the same. Note that Feature-Caps doesn't indicate which entity has this capability, o= nly that something does. And since this would presumably only be used if it= wasn't the UAC of the request, sending a subscribe to the contact address = of the UAC wouldn't make sense. [AA] Yes the GRUU of the intermediary would be needed but I think this can = be application specific and so this would be included in a feature tag regi= stered in the global tree as stated in the draft "RFC 6809 [1] provides tha= t addresses of intermediaries can be communicated as a value of an associat= ed feature-capability indicator so it would be appropriate to define featur= e capability indicators as part of the global tree to communicate the GRUU = of the intermediary and hence this is outside the scope of this document." = - RFC 6809 states " If additional data about a supported feature needs to = be conveyed, such as the address of the SIP entity that indicated support = of the feature, then the feature definition needs to define a way to convey= that information as a value of the associated feature-capability indicator= ." However I think the SIP specific capability indicators such as methods, = extensions and events should appropriately be registered in the SIP tree no= t as proprietary indicators in the global tree. If there is a conference bridge in the signaling path, then I would expect = it to be the UAC. [AA] Although a "standard" way to invoke a conference is to send a REFER to= the other UAs to invite them to the conference focus, in many deployments= a scenario exists where a call involves an IP-PBX or Telephony Application= Server (TAS) that can act as a focus for the conference. A participant of = a call can then create a conference by sending a REFER request in dialog to= the IP-PBX or TAS to use 3PCC to Invite other users to a conference. Reas= ons for this are = 1. Not all UAs support REFER, = 2. Many SBCs reject REFER requests going outside domains because of the pot= ential for charging fraud (referring to a premium rate number etc) = 3. A User receiving a REFER and then using an INVITE to join the conference= may be charged for initiating the call when the scenario is that the init= iator of the conference should be charged. = Problem is how to achieve the same behavior without dialog reuse which has = been deprecated by RFC 6665? As another example, consider section 5.1: Descrition: This Feature-capability indicator indicates that the intermediary supports audio as a streaming media type. ... Examples of typical use: An IP PBX indicating that it is capable of accepting and initiating sessions with audio as a streaming media type. This definition *implies* an assumption about the working environment - one= that AFAIK is new. It implies that you need to know that intermediaries su= pport a media type before you can use it. Would it be bad if there were no = intermediaries, and so none indicated this? What if some intermediary *did*= indicate support, but some other doesn't, but doesn't indicate that it doe= sn't? Bottom line: how would the presence or absence of this feature tag affect s= ubsequent usage? [AA] The absence of the streaming types does not indicate that the intermed= iary does not support the media type and SDP offer answer will ultimately d= etermine what can or cannot be used if another session is initiated involvi= ng the intermediary. However the presence of the media type in a Feature-ca= ps header field does explictly confirm that the intermediary does support t= he media type and in the scenario where a UA has a choice of multiple inter= mediaries it could use for a conference it might choose to use the one that= explicitly indicates it supports the media types the UA wants to use. As I= stated already I don't care that much about these streaming media types. I could go on, but this is enough for now. Thanks, Paul On 10/22/13 3:44 AM, Andrew Allen wrote: > Adam, Paul, Richard, Gonzalo > > I have submitted a new draft to sipcore to register a number of = > feature capability indicators in the SIP tree (based upon some of the = > existing SIP media feature tags). The draft can be found at: > > http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00. > txt > > Since there will not be a sipcore session at IETF#88 can we have an = > offline discussion on how to progress this draft (which hopefully is = > fairly straightforward as it just registers feature capabilities = > indicators with IANA). I wouldn't want to have to wait until March = > next year for a decision on progressing this. > > Andrew > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential = > information, privileged material (including material protected by the = > solicitor-client or other applicable privileges), or constitute = > non-public information. Any use of this information by anyone other = > than the intended recipient is prohibited. If you have received this = > transmission in error, please immediately reply to the sender and = > delete this information from your system. Use, dissemination, = > distribution, or reproduction of this transmission by unintended = > recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From gsalguei@cisco.com Fri Oct 25 10:51:01 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE33A11E81B7 for ; Fri, 25 Oct 2013 10:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAvv3ZmVcK-k for ; Fri, 25 Oct 2013 10:50:56 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8702411E8170 for ; Fri, 25 Oct 2013 10:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1573; q=dns/txt; s=iport; t=1382723456; x=1383933056; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fUnhAjSLbhOzdOfpRaDnUFtRX7QUJq1bpc1AF6oqs4M=; b=bgLw/T42UoQrceGSXG4PV/LVG9lu0VHV3tRLq6W3sOcwP85mpnFkjw2C IFdLqRmeT3x55nk0k0AOV3uJcpDD1SOTKJmpEShlwki6fUlf1ieQy9bNp uEsaQDn3FYpVkr0LfgTI1MYe8S8r6N+ooj3mM78db8+zJFazVyw5EJb6N Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFADKualKtJXG+/2dsb2JhbABZDoJ5OL5SS4EiFnSCJQEBAQMBAQEBNzQLBQsCAQgOCh4QJwslAgQOBRuHZgYNuU4EjhqBBjMHgx+BDQOYCpIHgmc/gXE X-IronPort-AV: E=Sophos;i="4.93,571,1378857600"; d="scan'208";a="276806347" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 25 Oct 2013 17:50:55 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9PHosCs031153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 17:50:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 12:50:54 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [sipcore] draft-johansson-sip-dual-stack Thread-Index: AQHOz2qzI4jONYz/JU+WCT5IOHuUfpoDA1eAgAALSQCAAqgKXw== Date: Fri, 25 Oct 2013 17:50:54 +0000 Message-ID: <7C27864E-E549-44EE-B4DF-2A7263FA4530@cisco.com> References: <5266E8EE.5060609@nostrum.com> <4F379740-43E9-4AF0-B80A-CA769F3B94C0@edvina.net>, <52682EB8.2030502@alum.mit.edu> In-Reply-To: <52682EB8.2030502@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" , "ipv6@sipforum.org" Subject: Re: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 17:51:01 -0000 > On Oct 23, 2013, at 4:17 PM, "Paul Kyzivat" wrote= : >=20 >> On 10/23/13 3:36 PM, Olle E. Johansson wrote: >>=20 >> Personally I think it's the duty of the IETF to make sure that the trans= ition to IPv6 works smoothly. Without work on dual stack, the SIP vendors w= ill not dare delivering dual stack solutions and we'll stay on IPv4-only VP= Ns. >> We have proven that there are a lot of issues with dual stack networks a= t SIPit tests. >=20 > I think so too. > But the only resources the IETF has to work on this are the ones reading = this mail. What we need to know is if there is a sufficient body of people = willing, and sufficiently knowledgeable, to *contribute*. Minimally by revi= ewing and commenting on drafts. But we need people who will do more - provi= de text, implement, test. I should point out that this deficiency was initially uncovered through int= erop and performance testing done by the SIP Forum (SIPit) and then subsequ= ently taken on as a work item by the SIP Forum IPv6 TG (copied here). So, = in addition to those who have offered their support and willingness to cont= ribute over the past few weeks, there are other interested (and qualified) = folks that could contribute to reviews, implement, test, etc. Cheers,=20 Gonzalo >=20 > So we are looking for people who will promise to do those things. >=20 > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Fri Oct 25 11:04:11 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A2011E8170 for ; Fri, 25 Oct 2013 11:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.705 X-Spam-Level: X-Spam-Status: No, score=-4.705 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7KmNIExnLOu for ; Fri, 25 Oct 2013 11:04:05 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A916D11E8311 for ; Fri, 25 Oct 2013 11:03:58 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-8c-526ab28ced31 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BA.B4.16099.C82BA625; Fri, 25 Oct 2013 20:03:57 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Fri, 25 Oct 2013 20:03:57 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0PLSyaYetkLS0EmxuQyZbVJK0ZoEJgKAgAAa8gCAAFL6gIAAv2uAgAAjYSCAAANOEv///4mAgAAmHmSAAAYQ1///6qSAgAAiBwKAAATWgQ== Date: Fri, 25 Oct 2013 18:03:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4F7024ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+JvjW7vpqwgg0v72Sy+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLdLMgo+/2etOPj5CXMDY08/axcjJ4eEgInEz563jBC2mMSF e+vZuhi5OIQEDjNK9Jz6wwzhLGGUaP4/E8jh4GATsJDo/qcN0iAioCmx/NtWdhBbWCBc4lzH UnaIeITEnz1zWUHKRQTqJKZcSwcJswioSuzdc5kZxOYV8JU4e/QI1K4uRolvV6aCJTgFPCXe XpoIdhwj0EHfT61hArGZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/9BPaMk8WPDJRaI+nyJPXu/ s0EsE5Q4OfMJywRGkVlIRs1CUjYLSRlE3EDi/bn5zBC2tsSyha+hbH2JjV/OMkLY1hLLTh1A UbOAkWMVI3tuYmZOernhJkZgBB3c8lt3B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwNh3ht//zuPeDuMtORv3/NaZPzVv87kz6+cKTyyWa/tp+36hkLiVtbXq k0y31Enxx+w/ST76MWnCdK/tGgKxsRkxh7I/rr2/2cTu9+87K6w0JcSuhSUtZ7x45Kd/aK3w VH/3AOFPK95Gs5bt9O277iwi/nj3g+QzsvlrL65wD33UYNVUvX3WnlwlluKMREMt5qLiRACv h5YGbgIAAA== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 18:04:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4F7024ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable (Moving to the SIPCORE list) Hi, > Also all the FCIs in the same Featire-Caps header field apply to the same= entity. > > E.g. that for > > Feature-Caps: *, +FCI1; +FCI2, *; +FCI3; +FCI4 > > FCI1 and FCI2 apply to one logical entity > and FCI3 and FCI4 apply to a different logical entity Correct. But, in general, keep in mind that a FCI value with an address does NOT aut= omatically indicates the address of the entity supporting the feature - unl= ess you explicitly say so in the FCI definition. It only provides an addres= s associated with a feature, and you need to define the semantics of it in = the FCI defintion. Example: I support the find-Paul feature, and I insert a FCI: Feature-Caps: *, +g.find-paul=3D"sip:pkyzivat@alum.mit.edu" Now, in this case the address does NOT point to my entity, but to Paul's en= tity. My entity supports a feature, which provides Paul's address. So, if the FCI says: Feature-Caps: *, +g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.method= s=3D"invite" ...it doesn't automatically mean that I can contact Paul using INVITE. By d= efault it means that MY entity supports the INVITE method - which from the = find-paul feature perspective is useless information. So, in the FCI specification for +g.find-paul, I would have to explictily d= escribe how the FCI works in conjunction with other FCIs. I would have to e= xplicitly say that, when used together +sip.methods, the +sip.methods indic= ates which SIP methods I can use to contact Paul (using the address provide= in the +g.find-paul FCI). Section 5.3.8 in RFC 6809 also says: "If there is additional information about the feature-capability indicator, it is recommended to describe such information. It can include, for example, names of related feature-capability indicators= ." So, in your case, I think the +g.3gpp.see_trans FCI specifiction would have= to specify how the FCI is used in conjuntion with other FCIs, including th= e +sip.method FCI. Something like: "When the session transfer request is sent to the address i= ndicated by the FCI value, the +sip.method FCI indicates which SIP methods = can be used." Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, October 25, 2013 12:01 PM Central Standard Time To: Andrew Allen; Paul Kyzivat ; Gonzalo Camarillo <= gonzalo.camarillo@ericsson.com> Cc: rlb@ipv.sx ; adam@nostrum.com ; mary.ietf= .barnes@gmail.com Subject: RE: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-= indicators Hi, >I think we can have an FCI > >Feature-Caps: *;+g.3ggp.sess_trans=3D=94sip:foo@example.com;gr=94 > >Indicating that the entity supports 3GPP session transfer and the address = where you send the session transfer request is sip:foo@example.com;gr Correct. The FCI itself indicates support of session transfer feature, and = the FCI value indicates the address associatd with the feature. >Also if I have: > >Feature-Caps: *;+g.3ggp.sess_trans=3Dsip:foo@example.com;gr; +sip.extensio= ns=3D=94replaces, tdialog=94; +sip.methods=3D=94invite, refer, bye, options= , update, prack=94 > > This means the entity supports 3GPP session transfer and the address wher= e you send the session transfer request is sip:foo@example.com;gr... Correct. > ...supports the replaces and target dialog extensions and supports the fo= llowing methods - invite, refer, bye, options, update, prack. Technically, what it means is that there is *AN* entity which supports the = features listed above, and the address is where you are to send the session= transfer request in order to trigger the 3GPP session transfer feature. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, October 25, 2013 10:25 AM To: Paul Kyzivat; Andrew Allen; Gonzalo Camarillo Cc: rlb@ipv.sx; adam@nostrum.com; mary.ietf.barnes@gmail.com Subject: RE: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-= indicators Hi, As Paul said, if one needs to provide address information associated with a= FCI, the address information cannot be a FCI of its own. It needs to be a = value of the FCI for which it is associated. Something like: Feature-Caps: *;+audio=3D"sip:foo@example.com" (Also note that the "+" sign is mandatory for all FCIs - no matter which re= gistry tree they belong to) Regards, Christer ________________________________ From: Paul Kyzivat [pkyzivat@alum.mit.edu] Sent: Friday, 25 October 2013 5:06 PM To: Andrew Allen; Gonzalo Camarillo Cc: rlb@ipv.sx; adam@nostrum.com; Christer Holmberg; mary.ietf.barnes@gmail.com Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-= indicators Andrew, (I see this is still on the private thread. I'll reply here, but this exchange should probably be reposted to the sipcore list as part of the public discussion of the draft.) On 10/24/13 10:41 PM, Andrew Allen wrote: > > Paul > > I am happy to do a revision with more details on the semantics of the cap= ability indicators. However I don't think it should be held to a very much = higher bar than the details in RFC 3840 and the other media feature tag RFC= s regarding the meaning of those tags. Keep in mind that the driving force for the definition of feature tags in 3840 was in support of callerprefs (3841). So the context for the use of feature tags was that they would be placed on Contacts in REGISTER requests. So you can interpret the definitions in that context: that a request sent to an AOR using callerprefs can affect the choice of which device the request goes to according to the capabilities it wants. In that context audio, video, isfocus all make sense. Their use on Contacts in dialogs was derivative to that: because callerpref support is optional, there is no guarantee that the device you reach via callerprefs will have the capabilities you requested. So the values in the contact help confirm what you got. Of course they have since been used other ways. And the descriptions of them don't necessarily reflect that. IMO that is a defect due to the evolution of use. I'm looking for the same sort of context for use with the feature-caps. In private discussion you indicated to me that you expected the feature caps to be grouped - with one of them giving the URI of the device that the other tags apply to. I guess this would end up looking something like: Feature-Caps: *;g.uri=3D"sip:foo@example.com";audio Feature-Caps: *;g.uri=3D"sip:bar@example.com";audio;video;isfocus Feature-Caps: *;g.uri=3D"sip:baz@example.com";text (I'm making up g.uri for the example.) And then presumably somebody on the signaling path will "shop" in the feature caps for the capabilities it wants, and then send a request to that URI, with the expectation that the UA responding will have those capabilities. > The semantics should be no different than those of the corresponding exi= sting media feature tag if it is present in the Contact header. Note that 6809 says: When a SIP entity receives a SIP request, or response, that contains one or more Feature-Caps header fields, the feature-capability indicators in the header field inform the entity about the features and capabilities supported by entities in the SIP message signaling path. The procedure by which features and capabilities are invoked are outside the scope of this specification and MUST be described by individual feature-capability indicator specifications. A Feature-Caps header field value cannot convey the address of the SIP entity that inserted the Feature-Caps header field. If additional data about a supported feature needs to be conveyed, such as the address of the SIP entity that indicated support of the feature, then the feature definition needs to define a way to convey that information as a value of the associated feature-capability indicator. This was discussed at length while that RFC was under consideration. Yet the definitions of the tags in *this* draft don't specify that. > The registration templates currently reference the RFC 3840 and the other= RFCs that define the other media feature tags that correspond to these fea= ture capability indicators. And those definitions were written to be understood in the context of 3840/3841. They make sense in that context, but not in *this* context. Thanks, Paul > But if more explicit detail is required then I can add some more text or= alternatively remove the less important ones if they are going to become r= at holes. The ones I regard as really important and urgent are sip.methods,= sip.extensions and sip.events the meaning of which I think should be quite= clear. > > Andrew > > ----- Original Message ----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time > To: Andrew Allen; Gonzalo.Camarillo@ericsson.com > > Cc: rlb@ipv.sx >; adam@n= ostrum.com >; christer.holmberg@ericsson.com= >; m= ary.ietf.barnes@gmail.com >; Paul Kyzivat > > Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-ca= p-indicators > > On 10/24/13 4:07 PM, Andrew Allen wrote: >> >> Paul >> >> Ok >> >> So we are basically where I thought we were at when I submitted the draf= t. >> >> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who = indicates interest) can have some offline discussion in Vancouver on whethe= r and how to progress this. > > As I indicated again on the sipcore list, I found the that the draft > didn't explain nearly enough to allow meaningful use of these. > I know you replied, and I will continue the conversation there. > But I will be opposed to these until and unless the draft (and notably > the descriptions of the tags) are clear about how one could figure out > what can do in the presence of the tags that one couldn't do without > them. AND, that the behavior that suggests doesn't "break" sip. (E.g., > by advocating a new and incompatible way to do something.) > > We can continue this on the sipcore list. > > Thanks, > Paul > >> Andrew >> >> ----- Original Message ----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >> To: Andrew Allen; Gonzalo Camarillo > >> Cc: Richard Barnes (rlb@ipv.sx) >; Adam Roach (adam@nostrum.com) >; Christer Holmberg (christer.holmberg@e= ricsson.com) >; Mary Barnes (mary.ietf.ba= rnes@gmail.com) < mary.ietf.barnes@gmail= .com> >> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-c= ap-indicators >> >> On 10/24/13 2:17 PM, Andrew Allen wrote: >>> Paul >>> >>> That is fine. Although Mary in her reply to me seemed to indicate maybe= there was a possibility to use some of the DISPATCH spare time for a SIPCO= RE session for this. Is that a possibility? >>> >>> I already replied to your post >> >> I discussed that with Adam. We decided we can't set a precedent to spin >> up a session to discuss a draft that hasn't had substantial (any) list >> discussion. >> >> But list discussion is always welcome. >> >> Sorry, >> Paul >> >>> Andrew >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, October 24, 2013 1:31 PM >>> To: Andrew Allen; Gonzalo Camarillo >>> Cc: Richard Barnes (rlb@ipv.sx); Adam Roach (adam@no= strum.com); Christer Holmberg (christer.holmberg@e= ricsson.com) >>> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-= cap-indicators >>> >>> Andrew, >>> >>> I spoke with Mary about it, and we concluded that dispatch isn't right = for this. (In addition to being clearly sipcore, it didn't meet the deadlin= e for dispatch.) I was wrong to encourage you that way. >>> >>> So no official live discussion in Vancouver. (But informal discussion >>> fine.) >>> >>> I'll resend my private comments to the sipcore list to kickstart some d= iscussion there. >>> >>> Thanks, >>> Paul >>> >>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>> I just emailed Mary asking for agenda time. Should I cancel that reque= st? >>>> >>>> -----Original Message----- >>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>> Sent: Thursday, October 24, 2013 1:00 PM >>>> To: Paul Kyzivat >>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx); Adam= Roach >>>> (adam@nostrum.com); Christer Holmberg (christ= er.holmberg@ericsson.com) >>>> Subject: Re: New sipcore draft submission >>>> draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> Hi Paul, >>>> >>>> given that you think this belongs to SIPCORE, I do not see the need to= run it through DISPATCH. Please, start technical discussions on the draft = on the SIPCORE list. >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>> Paul >>>>>> >>>>>> Thanks for reviewing the draft already and giving me early feedback. >>>>>> >>>>>> My responses below inline (prepended with [AA). >>>>>> >>>>>> Can I ask the ADs to determine ASAP if this needs to go to DISPATCH >>>>>> first or not. As outlined below my view is that it is unnecessary >>>>>> for every little thing to go to DISPATCH as this just creates >>>>>> additional delay and overhead. If it is to be discussed in DISPATCH >>>>>> then I definitely would want agenda time atIETF#88 for this. >>>>> >>>>> Having now seen Andrew's responses to my initial questions, I think >>>>> this >>>>> *needs* to be carefully considered by sipcore. IMO this has the >>>>> potential to create a dialect of sip that is incompatible with normal >>>>> usage. (Maybe IMS has already done that. But this will make it >>>>> worse.) >>>>> >>>>> But if there is a desire to discuss it publicly in Vancouver then >>>>> dispatch is the opportunity and so some discussion on the dispatch >>>>> list in advance of that would be appropriate. >>>>> >>>>> I'll defer to the ADs on this. >>>>> >>>>> More inline. >>>>> >>>>>> Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx); Go= nzalo Camarillo >>>>>> (Gonzalo.Camarillo@ericsson.com); Adam Roach (adam@nostrum.com) >>>>>> Subject: Re: New sipcore draft submission >>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>> >>>>>> Andrew, >>>>>> >>>>>> On a legalistic note, its questionable to me whether this kind of >>>>>> action falls within the scope of sipcore. OTOH, among existing wgs, >>>>>> sipcore is probably the best suited to discuss the proposal. We >>>>>> could take it to DISPATCH. I think DISPATCH has extra time in its >>>>>> agenda for Vancouver, so that might be one option for you. But then >>>>>> I don't know where dispatch would dispatch it. It may be that AD >>>>>> sponsored is the best way to go. >>>>>> >>>>>> [AA] It seemed to me that sipcore was the right place. This draft >>>>>> registers feature-capability indicators in a registry that was >>>>>> created by a sipcore RFC (RFC 6809). You could in my view make an >>>>>> argument that this should even have been done as part of RFC 6809. >>>>> >>>>> If this was just a matter of registering some new feature caps that >>>>> were not controversial, then I don't think sipcore needs to be involv= ed. >>>>> >>>>> But as I mentioned above, I do consider these controversial. >>>>> >>>>>> Discussing it now on the dispatch list would be a good start toward >>>>>> discussing it at the dispatch session. >>>>>> >>>>>> [AA] Can I ask the ADs to determine if this needs to go to DISPATCH >>>>>> first or not. My view is that it is unnecessary for every little >>>>>> thing to go to DISPATCH as this just creates additional delay and ov= erhead. >>>>>> This just registers some indicators in an existing IANA registry and >>>>>> is not (or should not be IMHO) a major project. >>>>> >>>>> To me this is a matter of whether you want to be opportunistic. >>>>> If this went to dispatch I would now recommend that it be dispatched >>>>> to sipcore. So its a matter of whether you want to talk about it in >>>>> the dispatch meeting. >>>>> >>>>>> Regarding substance, this draft troubles me. It takes feature-caps >>>>>> in exactly the direction that I found most concerning about the >>>>>> mechanism in the first place. >>>>>> >>>>>> Your draft partitions the existing media feature tags into two sets >>>>>> - those that would be useful as feature-capability-indicators, and >>>>>> those that aren't. But I see no explanation of the criteria used to >>>>>> make this distinction, nor can I think of one. >>>>>> >>>>>> [AA] I based this decision on the following criteria: If a feature >>>>>> tag was potentially at all useful for an intermediary to indicate it >>>>>> then include it in the registry. The ones not included are either >>>>>> directly associated with the user (intermediaries are not directly >>>>>> associated with the user) or would only ever have one value (e.g >>>>>> automata). I am not sure that every feature-capability indicator >>>>>> proposed to be registered is actually useful but then I don't think >>>>>> every media feature tag registered by RFC 3840 is either (I doubt >>>>>> very much if there are implementation using the sip.application or >>>>>> sip.control feature tags). I don't think RFC 3840 goes into a lot of >>>>>> details justifying of ever registered media feature tag and >>>>>> specifying the details of how they would be used either. I am >>>>>> willing to remove any feature-capability indicators that are >>>>>> controversial except that I think we definitely need sip.extensions,= sip.methods and sip.events. >>>>>> There is a significant overhead to writing an >>>>> d progressing internet drafts so my view is lets register all that >>>>> might be remotely useful in the same document. >>>>> >>>>> The judgement of "useful" is reasonable. But I still can't discern >>>>> what the use is from the iana registration descriptions. >>>>> >>>>>> For the ones that you have requested feature capability indicators, >>>>>> I cannot figure out what using them would mean. For example, when I >>>>>> see isFocus on a Contact header I know I am in a conference, and >>>>>> that I can subscribe to the conference event package at the contact >>>>>> URI. If I see isFocus in a Feature-Caps header, what does it mean? >>>>>> What can I do once I know this? >>>>>> >>>>>> Section 5.14 of this draft says: >>>>>> >>>>>> This Feature-capability indicator indicates that the int= ermediary >>>>>> is a conference server, also known as a focus, and is ca= pable of >>>>>> mixing together the media for all calls to the same URI. >>>>>> ... >>>>>> Examples of typical use: A conference bridge indicati= ng >>>>>> that it >>>>>> is a conference bridge and is capable of acting as a >>>>>> conference >>>>>> focus for this session. >>>>>> >>>>>> [AA] the presence of isfocus in a Feature-Caps header field means >>>>>> that a UA can initiate a conference by sending a REFER request to >>>>>> the intermediary to invite another user and create a multi user >>>>>> conference from the 1-1 session. >>>>>> >>>>>> Note that Feature-Caps doesn't indicate which entity has this >>>>>> capability, only that something does. And since this would >>>>>> presumably only be used if it wasn't the UAC of the request, sending >>>>>> a subscribe to the contact address of the UAC wouldn't make sense. >>>>>> >>>>>> [AA] Yes the GRUU of the intermediary would be needed but I consider >>>>>> this application specific and so this would be included in a feature >>>>>> tag registered in the global tree as stated in the draft "RFC 6809 >>>>>> [1] provides that addresses of intermediaries can be communicated as >>>>>> a value of an associated feature-capability indicator so it would be >>>>>> appropriate to define feature capability indicators as part of the >>>>>> global tree to communicate the GRUU of the intermediary and hence >>>>>> this is outside the scope of this document." - RFC 6809 states " If >>>>>> additional data about a supported feature needs to be conveyed, such >>>>>> as the address of the SIP entity that indicated support of the >>>>>> feature, then the feature definition needs to define a way to convey >>>>>> that information as a value of the associated feature-capability >>>>>> indicator." However I think the SIP specific capability indicators >>>>>> such as methods, extensions and events should appropriately be >>>>>> registered in the SIP tree not as proprietary indicator >>>>> s in the global tree. >>>>> >>>>> So you have defined a sip tree feature tag that is only useful in >>>>> conjunction with another feature tag from the global tree. >>>>> And the description of this feature tag doesn't even mention that. >>>>> >>>>> And this all implies a completely non-standard call model - doing >>>>> conferencing in a way inconsistent with RFC 4579. >>>>> >>>>> ISTM that if 4579 doesn't work for you then you should be back >>>>> proposing extensions/revisions to it. >>>>> >>>>>> If there is a conference bridge in the signaling path, then I would >>>>>> expect it to be the UAC. >>>>>> >>>>>> [AA] Although a "standard" way to invoke a conference is to send a >>>>>> REFER to the other UAs to invite them to the conference focus, in >>>>>> many deployments a scenario exists where a call involves an IP-PBX >>>>>> or Telephony Application Server (TAS) that can act as a focus for >>>>>> the conference. A participant of a call can then create a conference >>>>>> by sending a REFER request in dialog to the IP-PBX or TAS to use >>>>>> 3PCC to Invite other users to a conference. Reasons for this are 1. >>>>>> Not all UAs support REFER, >>>>> >>>>> So you are saying the intermediary isn't a focus (its a B2BUA), but >>>>> it *could become* a focus. >>>>> >>>>> The concept that a dialog may contain intermediaries that can be >>>>> addressed to do stuff is not part of any sip standard that I am aware >>>>> of. I don't care too much as long as the "stuff" is application stuff >>>>> that is outside the scope of sip. But when it is alternative ways to >>>>> do stuff that sip supports, then I get upset. >>>>> >>>>>> 2. Many SBCs reject REFER requests going outside domains because of >>>>>> the potential for charging fraud (referring to a premium rate number >>>>>> etc) 3. A User receiving a REFER and then using an INVITE to join >>>>>> the conference may be charged for initiating the call when the >>>>>> scenario is that the initiator of the conference should be charged. >>>>>> 4. No need to obtain and distribute conference URIs. >>>>>> Problem is how to achieve the same behavior without dialog reuse >>>>>> which has been deprecated by RFC 6665? >>>>> >>>>> Then maybe the problem needs to be brought up, and a standard >>>>> solution proposed, rather than simply enabling a proprietary mechanis= m. >>>>> >>>>>> As another example, consider section 5.1: >>>>>> >>>>>> Descrition: >>>>>> This Feature-capability indicator indicates that the int= ermediary >>>>>> supports audio as a streaming media type. >>>>>> ... >>>>>> Examples of typical use: An IP PBX indicating that it= is >>>>>> capable of accepting and initiating sessions with aud= io as a >>>>>> streaming media type. >>>>>> >>>>>> This definition *implies* an assumption about the working >>>>>> environment >>>>>> - one that AFAIK is new. It implies that you need to know that >>>>>> intermediaries support a media type before you can use it. Would it >>>>>> be bad if there were no intermediaries, and so none indicated this? >>>>>> What if some intermediary *did* indicate support, but some other >>>>>> doesn't, but doesn't indicate that it doesn't? >>>>>> >>>>>> Bottom line: how would the presence or absence of this feature tag >>>>>> affect subsequent usage? >>>>>> >>>>>> [AA] The absence of the streaming types does not indicate that the >>>>>> intermediary does not support the media type and SDP offer answer >>>>>> will ultimately determine what can or cannot be used if another >>>>>> session is initiated involving the intermediary. However the >>>>>> presence of the media type in a Feature-caps header field does >>>>>> explictly confirm that the intermediary does support the media type >>>>>> and in the scenario where a UA has a choice of multiple >>>>>> intermediaries it could use for a conference it might choose to use >>>>>> the one that explicitly indicates it supports the media types the UA= wants to use. >>>>> >>>>> So the UA will be able to discover that *some* intermediary supports >>>>> media it is interested in. And it can tell that *some* intermediary >>>>> says it is a focus. It doesn't know if they are the same intermediary= . >>>>> >>>>> And then via some other feature tag it obtains the URI of *some* >>>>> intermediary on the signaling path. Or maybe it gets more than one of >>>>> these. >>>>> >>>>> It then makes a leap of faith and conflates all those things, to >>>>> determine that the URI identifies a focus that supports this media ty= pe. >>>>> >>>>> Even then, exactly what does that mean? It may or may not mean that >>>>> it supports mixing that media type in a conference. >>>>> >>>>>> As I stated already I don't care that much about these streaming >>>>>> media types. >>>>> >>>>>> I could go on, but this is enough for now. >>>>>> >>>>>> [AA] My motivation for this is that currently 3GPP are updating >>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>> >>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with >>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather than >>>>>> forwarding it all the way to the remote UA. >>>>> >>>>> And 6665 deprecates dial reuse in most of those cases. >>>>> Without dialog reuse, the intermediaries don't get an opportunity to >>>>> intercept those. >>>>> >>>>>> In order to know that an intermediary supports the target dialog >>>>>> mechanism needed for a REFER request sent outside the dialog to >>>>>> work we need sip.extensions as a feature-capability indicator. In >>>>>> order to know that the needed event package is supported by the >>>>>> intermediary so we can SUBSCROBE outside the dialog to an >>>>>> intermediary we need sip.events as a feature-capability indicator. >>>>> >>>>> Then I think you should be back here with a problem statement and a >>>>> request for how to get sip to solve it. >>>>> >>>>> And you should touch base with Christer on this. He may have a >>>>> different opinion on the relevance of feature-caps as a solution. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>> >>>>>>> I have submitted a new draft to sipcore to register a number of >>>>>>> feature capability indicators in the SIP tree (based upon some of >>>>>>> the existing SIP media feature tags). The draft can be found at: >>>>>>> >>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-= 00. >>>>>>> txt >>>>>>> >>>>>>> Since there will not be a sipcore session at IETF#88 can we have >>>>>>> an offline discussion on how to progress this draft (which >>>>>>> hopefully is fairly straightforward as it just registers feature >>>>>>> capabilities indicators with IANA). I wouldn't want to have to wait >>>>>>> until March next year for a decision on progressing this. >>>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> ------------------------------------------------------------------- >>>>>>> - >>>>>>> - This transmission (including any attachments) may contain >>>>>>> confidential information, privileged material (including material >>>>>>> protected by the solicitor-client or other applicable privileges), >>>>>>> or constitute non-public information. Any use of this information >>>>>>> by anyone other than the intended recipient is prohibited. If you >>>>>>> have received this transmission in error, please immediately reply >>>>>>> to the sender and delete this information from your system. Use, >>>>>>> dissemination, distribution, or reproduction of this transmission >>>>>>> by unintended recipients is not authorized and may be unlawful. >>>>>> >>>>>> -------------------------------------------------------------------- >>>>>> - This transmission (including any attachments) may contain >>>>>> confidential information, privileged material (including material >>>>>> protected by the solicitor-client or other applicable privileges), >>>>>> or constitute non-public information. Any use of this information by >>>>>> anyone other than the intended recipient is prohibited. If you have >>>>>> received this transmission in error, please immediately reply to the >>>>>> sender and delete this information from your system. Use, >>>>>> dissemination, distribution, or reproduction of this transmission by >>>>>> unintended recipients is not authorized and may be unlawful. >>>>>> >>>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the soli= citor-client or other applicable privileges), or constitute non-public info= rmation. Any use of this information by anyone other than the intended reci= pient is prohibited. If you have received this transmission in error, pleas= e immediately reply to the sender and delete this information from your sys= tem. Use, dissemination, distribution, or reproduction of this transmission= by unintended recipients is not authorized and may be unlawful. >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the solic= itor-client or other applicable privileges), or constitute non-public infor= mation. Any use of this information by anyone other than the intended recip= ient is prohibited. If you have received this transmission in error, please= immediately reply to the sender and delete this information from your syst= em. Use, dissemination, distribution, or reproduction of this transmission = by unintended recipients is not authorized and may be unlawful. >>> >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential i= nformation, privileged material (including material protected by the solici= tor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recipi= ent is prohibited. If you have received this transmission in error, please = immediately reply to the sender and delete this information from your syste= m. Use, dissemination, distribution, or reproduction of this transmission b= y unintended recipients is not authorized and may be unlawful. >> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_7594FB04B1934943A5C02806D1A2204B1C4F7024ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

 

(Moving to the SIPCORE list)

 

Hi,


> Also all the FCIs in the same Featire-Caps header field apply to the s= ame entity.
>
> E.g. that for
>
> Feature-Caps: *, +FCI1; +FCI2, *; +FCI3; +FCI4
>
> FCI1 and FCI2 apply to one logical entity
> and FCI3 and FCI4 apply to a different logical entity

 

Correct.

 

But, in general, keep in mind that a FCI value w= ith an address does NOT automatically indicates the address of th= e entity supporting the feature - unless you explicitly say so in the = FCI definition. It only provides an address associated with a feature, and you need to define the semantics of it in the FCI defi= ntion.

 

Example:

 

I support the find-Paul feature, and I insert a = FCI:

 

    Feature-Caps: *, +g.= find-paul=3D"sip:pkyzivat@alum.mit.edu"

Now, in this case the address does NOT poin= t to my entity, but to Paul's entity. My entity supports a feature, which p= rovides Paul's address.

 

So, if the FCI says:

 

    Feature-Caps: *, +g.= find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.methods=3D"= invite"

 

...it doesn't automatically mean that I can cont= act Paul using INVITE. By default it means that MY entity supports the INVI= TE method - which from the find-paul feature perspective is useless informa= tion.

 

So, in the FCI specification for +g.find-pau= l, I would have to explictily describe how the FCI works in conjunction wit= h other FCIs. I would have to explicitly say that, when used together&= nbsp;+sip.methods, the +sip.methods indicates which SIP methods I can use to contact Paul (using the address provide in the &#= 43;g.find-paul FCI).

 

Section 5.3.8 in RFC 6809 also says:

 

    "If there is additi= onal information about the feature-capability
       indicator, it is recommended to d= escribe such information.  It can
       include, for example, nam= es of related feature-capability indicators."

So, in your case, I think the +g.3gpp.see_trans FCI specifiction would = have to specify how the FCI is used in conjuntion with other FCIs, inc= luding the +sip.method FCI.

 

Something like: "When the session transfer = request is sent to the address indicated by the FCI value, the +si= p.method FCI indicates which SIP methods can be used."

 

Regards,

 

Christer


 

 
From: Christer Holmberg [mailto:christer.holmberg@eric= sson.com]
Sent: Friday, October 25, 2013 12:01 PM Central Standard Time
To: Andrew Allen; Paul Kyzivat <pkyzivat@alum.mit.edu>; Gonzal= o Camarillo <gonzalo.camarillo@ericsson.com>
Cc: rlb@ipv.sx <rlb@ipv.sx>; adam@nostrum.com <adam@nostrum= .com>; mary.ietf.barnes@gmail.com <mary.ietf.barnes@gmail.com>
Subject: RE: New sipcore draft submission draft-allen-sipcore-sip-tr= ee-cap-indicators
 

Hi,

 

>I think = we can have an FCI

><= /p>

>Feature-Caps: *;+= ;g.3ggp.sess_trans=3D=94sip:foo@example.com;gr=94

> 

>Indicati= ng that the entity supports 3GPP session transfer and the address where you= send the session transfer request is sip:foo@example.com;gr

 

= Correct. The FCI itself indicates support of session transfer feature, and = the FCI value indicates the address associatd with the feature.

 

>Also if I= have:

> 

>Feature-Caps: *;+= ;g.3ggp.sess_trans=3Ds= ip:foo@example.com;gr; +sip.extensions=3D=94replaces, tdialog=94; &= #43;sip.methods=3D=94invite, refer, bye, options, update, prack=94

> 

> This me= ans the entity supports 3GPP session transfer and the address where you sen= d the session transfer request is sip:foo= @example.com;gr...

 =

Correct.

 =

> ...suppo= rts the replaces and target dialog extensions and supports the following me= thods - invite, refer, bye, options, update, prack.

 =

Technically, what it means is that= there is *AN* entity which supports the features listed above, and the address i= s where you are to send the session transfer request in order to = trigger the 3GPP session transfer feature.

 

= Regards,

=  

= Christer

=

 

  

From: Chri= ster Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Friday, October 25, 2013 10:25 AM
To: Paul Kyzivat; Andrew Allen; Gonzalo Camarillo
Cc: rlb@ipv.sx; adam@nostrum.com; mary.ietf.barnes@gmail.com
Subject: RE: New sipcore draft submission draft-allen-sipcore-sip-tr= ee-cap-indicators

 

 

 

Hi,

 

As Paul said, if one needs to provide addres= s information associated with a FCI, the address information cannot be= a FCI of its own. It needs to be a value of the FCI for which it is associated.

 

Something like:

 

Feature-Caps: *;+audio=3D"sip:foo@example.com"

 

(Also note that the "+" s= ign is mandatory for all FCIs - no matter which registry tree they belong t= o)

 

Regards,

 

Christer

 

 

 

 

From: Paul Kyzivat [pkyziv= at@alum.mit.edu]
Sent: Friday, 25 October 2013 5:06 PM
To: Andrew Allen; Gonzalo Camarillo
Cc: rlb@ipv.sx; = adam@nostrum.com; Christer Holmberg; mary.ietf.barnes@gmail.com
Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tr= ee-cap-indicators

Andrew,

(I see this is still on the private thread. I'll reply here, but this
exchange should probably be reposted to the sipcore list as part of the public discussion of the draft.)

On 10/24/13 10:41 PM, Andrew Allen wrote:
>
> Paul
>
> I am happy to do a revision with more details on the semantics of the = capability indicators. However I don't think it should be held to a very mu= ch higher bar than the details in RFC 3840 and the other media feature tag = RFCs regarding the meaning of those tags.

Keep in mind that the driving force for the definition of feature tags
in 3840 was in support of callerprefs (3841). So the context for the use of feature tags was that they would be placed on Contacts in REGISTER
requests. So you can interpret the definitions in that context: that a
request sent to an AOR using callerprefs can affect the choice of which device the request goes to according to the capabilities it wants. In
that context audio, video, isfocus all make sense.

Their use on Contacts in dialogs was derivative to that: because
callerpref support is optional, there is no guarantee that the device
you reach via callerprefs will have the capabilities you requested. So
the values in the contact help confirm what you got.

Of course they have since been used other ways. And the descriptions of them don't necessarily reflect that. IMO that is a defect due to the
evolution of use.

I'm looking for the same sort of context for use with the feature-caps.

In private discussion you indicated to me that you expected the feature caps to be grouped - with one of them giving the URI of the device that the other tags apply to. I guess this would end up looking something like:<= br>
   Feature-Caps: *;g.uri=3D"sip:foo@example.com";audio
   Feature-Caps: *;g.uri=3D"sip:bar@example.com";audio;video;isfocus
   Feature-Caps: *;g.uri=3D"sip:baz@example.com";text

(I'm making up g.uri for the example.)

And then presumably somebody on the signaling path will "shop" in= the
feature caps for the capabilities it wants, and then send a request to
that URI, with the expectation that the UA responding will have those
capabilities.

> The semantics should be no different than those of  the correspon= ding existing media  feature tag if it is present in the Contact heade= r.

Note that 6809 says:

    When a SIP entity receives a SIP request, or response, t= hat contains
    one or more Feature-Caps header fields, the feature-capa= bility
    indicators in the header field inform the entity about t= he features
    and capabilities supported by entities in the SIP messag= e signaling
    path.  The procedure by which features and capabili= ties are invoked
    are outside the scope of this specification and MUST be = described by
    individual feature-capability indicator specifications.<= br>
    A Feature-Caps header field value cannot convey the addr= ess of the
    SIP entity that inserted the Feature-Caps header field.&= nbsp; If
    additional data about a supported feature needs to be co= nveyed, such
    as the address of the SIP entity that indicated support = of the
    feature, then the feature definition needs to define a w= ay to convey
    that information as a value of the associated feature-ca= pability
    indicator.

This was discussed at length while that RFC was under consideration. Yet the definitions of the tags in *this* draft don't specify that.

> The registration templates currently reference the RFC 3840 and the ot= her RFCs that define the other media feature tags that correspond to these = feature capability indicators.

And those definitions were written to be understood in the context of
3840/3841. They make sense in that context, but not in *this* context.

        Thanks,
        Paul

> But if more explicit detail is required then I can add some more text&= nbsp; or alternatively remove the less important ones if they are going to = become rat holes. The ones I regard as really important and urgent are sip.= methods, sip.extensions and sip.events the meaning of which I think should be quite clear.
>
> Andrew
>
> ----- Original Message -----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time
> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com <Gonzalo.Camarillo@ericsson.com>
> Cc: rlb@ipv.sx <= ;rlb@ipv.sx>; adam@nostrum.com = <adam@nostrum.com<= /a>>; christe= r.holmberg@ericsson.com <christer.holmberg@ericsson.com>; mary.ietf.b= arnes@gmail.com <mary.ietf.barnes@gmail.com>; Paul Kyzivat <pkyzivat@alum.mit.edu>
> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree= -cap-indicators
>
> On 10/24/13 4:07 PM, Andrew Allen wrote:
>>
>> Paul
>>
>> Ok
>>
>> So we are basically where I thought we were at when I submitted th= e draft.
>>
>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone els= e who indicates interest) can have some offline discussion in Vancouver on = whether and how to progress this.
>
> As I indicated again on the sipcore list, I found the that the draft > didn't explain nearly enough to allow meaningful use of these.
> I know you replied, and I will continue the conversation there.
> But I will be opposed to these until and unless the draft (and notably=
> the descriptions of the tags) are clear about how one could figure out=
> what can do in the presence of the tags that one couldn't do without > them. AND, that the behavior that suggests doesn't "break" s= ip. (E.g.,
> by advocating a new and incompatible way to do something.)
>
> We can continue this on the sipcore list.
>
>        Thanks,
>        Paul
>
>> Andrew
>>
>> ----- Original Message -----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >> To: Andrew Allen; Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
>> Cc: Richard Barnes (rlb@ipv.sx) <rlb@i= pv.sx>; Adam Roach (adam@nostrum.com) <adam@nostrum.com>; Christer Holmberg (christer.holmberg@ericsson.com) <christer.holmberg@ericsson.co= m>; Mary Barnes (mary.ietf.barnes@gmail.com) < mary.= ietf.barnes@gmail.com>
>> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-= tree-cap-indicators
>>
>> On 10/24/13 2:17 PM, Andrew Allen wrote:
>>> Paul
>>>
>>> That is fine. Although Mary in her reply to me seemed to indic= ate maybe there was a possibility to use some of the DISPATCH spare time fo= r a SIPCORE session for this. Is that a possibility?
>>>
>>> I already replied to your post
>>
>> I discussed that with Adam. We decided we can't set a precedent to= spin
>> up a session to discuss a draft that hasn't had substantial (any) = list
>> discussion.
>>
>> But list discussion is always welcome.
>>
>>       Sorry,
>>       Paul
>>
>>> Andrew
>>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>> Sent: Thursday, October 24, 2013 1:31 PM
>>> To: Andrew Allen; Gonzalo Camarillo
>>> Cc: Richard Barnes (rlb@ipv.sx); Adam Roach (adam@nostrum.com); Christer Holmberg (christer.holmberg@ericsson= .com)
>>> Subject: Re: New sipcore draft submission draft-allen-sipcore-= sip-tree-cap-indicators
>>>
>>> Andrew,
>>>
>>> I spoke with Mary about it, and we concluded that dispatch isn= 't right for this. (In addition to being clearly sipcore, it didn't meet th= e deadline for dispatch.) I was wrong to encourage you that way.
>>>
>>> So no official live discussion in Vancouver. (But informal dis= cussion
>>> fine.)
>>>
>>> I'll resend my private comments to the sipcore list to kicksta= rt some discussion there.
>>>
>>>      Thanks,
>>>      Paul
>>>
>>> On 10/24/13 1:01 PM, Andrew Allen wrote:
>>>> I just emailed Mary asking for agenda time. Should I cance= l that request?
>>>>
>>>> -----Original Message-----
>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
>>>> Sent: Thursday, October 24, 2013 1:00 PM
>>>> To: Paul Kyzivat
>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx); Adam Roach
>>>> (ada= m@nostrum.com); Christer Holmberg (christer.holmberg@ericsson.com)
>>>> Subject: Re: New sipcore draft submission
>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>
>>>> Hi Paul,
>>>>
>>>> given that you think this belongs to SIPCORE, I do not see= the need to run it through DISPATCH. Please, start technical discussions o= n the draft on the SIPCORE list.
>>>>
>>>> Thanks,
>>>>
>>>> Gonzalo
>>>>
>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote:
>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote:
>>>>>> Paul
>>>>>>
>>>>>> Thanks for reviewing the draft already and giving = me early feedback.
>>>>>>
>>>>>> My responses below inline (prepended with [AA). >>>>>>
>>>>>> Can I ask the ADs to determine ASAP if this needs = to go to DISPATCH
>>>>>> first or not. As outlined below my view is that it= is unnecessary
>>>>>> for every little thing to go to DISPATCH as this j= ust creates
>>>>>> additional delay and overhead. If it is to be disc= ussed in DISPATCH
>>>>>> then I definitely would want agenda time atIETF#88= for this.
>>>>>
>>>>> Having now seen Andrew's responses to my initial quest= ions, I think
>>>>> this
>>>>> *needs* to be carefully considered by sipcore. IMO thi= s has the
>>>>> potential to create a dialect of sip that is incompati= ble with normal
>>>>> usage. (Maybe IMS has already done that. But this will= make it
>>>>> worse.)
>>>>>
>>>>> But if there is a desire to discuss it publicly in Van= couver then
>>>>> dispatch is the opportunity and so some discussion on = the dispatch
>>>>> list in advance of that would be appropriate.
>>>>>
>>>>> I'll defer to the ADs on this.
>>>>>
>>>>> More inline.
>>>>>
>>>>>> Andrew
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM
>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx); Gonzalo Camarillo
>>>>>> (Gonzalo.Camarillo@ericsson.com); Adam Roach (adam@nostrum.com)
>>>>>> Subject: Re: New sipcore draft submission
>>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>>
>>>>>> Andrew,
>>>>>>
>>>>>> On a legalistic note, its questionable to me wheth= er this kind of
>>>>>> action falls within the scope of sipcore. OTOH, am= ong existing wgs,
>>>>>> sipcore is probably the best suited to discuss the= proposal. We
>>>>>> could take it to DISPATCH. I think DISPATCH has ex= tra time in its
>>>>>> agenda for Vancouver, so that might be one option = for you. But then
>>>>>> I don't know where dispatch would dispatch it. It = may be that AD
>>>>>> sponsored is the best way to go.
>>>>>>
>>>>>> [AA] It seemed to me that sipcore was the right pl= ace. This draft
>>>>>> registers feature-capability indicators in a regis= try that was
>>>>>> created by a sipcore RFC (RFC 6809). You could in = my view make an
>>>>>> argument that this should even have been done as p= art of RFC 6809.
>>>>>
>>>>> If this was just a matter of registering some new feat= ure caps that
>>>>> were not controversial, then I don't think sipcore nee= ds to be involved.
>>>>>
>>>>> But as I mentioned above, I do consider these controve= rsial.
>>>>>
>>>>>> Discussing it now on the dispatch list would be a = good start toward
>>>>>> discussing it at the dispatch session.
>>>>>>
>>>>>> [AA] Can I ask the ADs to determine if this needs = to go to DISPATCH
>>>>>> first or not. My view is that it is unnecessary fo= r every little
>>>>>> thing to go to DISPATCH as this just creates addit= ional delay and overhead.
>>>>>> This just registers some indicators in an existing= IANA registry and
>>>>>> is not (or should not be IMHO) a major project. >>>>>
>>>>> To me this is a matter of whether you want to be oppor= tunistic.
>>>>> If this went to dispatch I would now recommend that it= be dispatched
>>>>> to sipcore. So its a matter of whether you want to tal= k about it in
>>>>> the dispatch meeting.
>>>>>
>>>>>> Regarding substance, this draft troubles me. It ta= kes feature-caps
>>>>>> in exactly the direction that I found most concern= ing about the
>>>>>> mechanism in the first place.
>>>>>>
>>>>>> Your draft partitions the existing media feature t= ags into two sets
>>>>>> - those that would be useful as feature-capability= -indicators, and
>>>>>> those that aren't. But I see no explanation of the= criteria used to
>>>>>> make this distinction, nor can I think of one.
>>>>>>
>>>>>> [AA] I based this decision on the following criter= ia: If a feature
>>>>>> tag was potentially at all useful for an intermedi= ary to indicate it
>>>>>> then include it in the registry. The ones not incl= uded are either
>>>>>> directly associated with the user (intermediaries = are not  directly
>>>>>> associated with the user) or would only ever have = one value (e.g
>>>>>> automata).  I am not sure that every feature-= capability indicator
>>>>>> proposed to be registered is actually useful but t= hen I don't think
>>>>>> every media feature tag registered by RFC 3840 is = either (I doubt
>>>>>> very much if there are implementation using the si= p.application or
>>>>>> sip.control feature tags). I don't think RFC 3840 = goes into a lot of
>>>>>> details justifying of ever registered media featur= e tag and
>>>>>> specifying the details of how they would be used e= ither.  I am
>>>>>> willing to remove any feature-capability indicator= s that are
>>>>>> controversial except that I think we definitely ne= ed sip.extensions, sip.methods and sip.events.
>>>>>> There is a significant overhead to writing an
>>>>> d progressing internet drafts so my view is lets regis= ter all that
>>>>> might be remotely useful in the same document.
>>>>>
>>>>> The judgement of "useful" is reasonable. But= I still can't discern
>>>>> what the use is from the iana registration description= s.
>>>>>
>>>>>> For the ones that you have requested feature capab= ility indicators,
>>>>>> I cannot figure out what using them would mean. Fo= r example, when I
>>>>>> see isFocus on a Contact header I know I am in a c= onference, and
>>>>>> that I can subscribe to the conference event packa= ge at the contact
>>>>>> URI. If I see isFocus in a Feature-Caps header, wh= at does it mean?
>>>>>> What can I do once I know this?
>>>>>>
>>>>>> Section 5.14 of this draft says:
>>>>>>
>>>>>>        &nb= sp;    This Feature-capability indicator indicates that the = intermediary
>>>>>>        &nb= sp;    is a conference server, also known as a focus, and is= capable of
>>>>>>        &nb= sp;    mixing together the media for all calls to the same U= RI.
>>>>>> ...
>>>>>>        &nb= sp;       Examples of typical use: A conferen= ce bridge indicating
>>>>>> that it
>>>>>>        &nb= sp;       is a conference bridge and is capab= le of acting as a
>>>>>> conference
>>>>>>        &nb= sp;       focus for this session.
>>>>>>
>>>>>> [AA] the presence of isfocus in a Feature-Caps hea= der field means
>>>>>> that a UA can initiate a conference by sending a R= EFER request to
>>>>>> the intermediary to invite another user and create= a multi user
>>>>>> conference from the 1-1 session.
>>>>>>
>>>>>> Note that Feature-Caps doesn't indicate which enti= ty has this
>>>>>> capability, only that something does. And since th= is would
>>>>>> presumably only be used if it wasn't the UAC of th= e request, sending
>>>>>> a subscribe to the contact address of the UAC woul= dn't make sense.
>>>>>>
>>>>>> [AA] Yes the GRUU of the intermediary would be nee= ded but I consider
>>>>>> this application specific and so this would be inc= luded in a feature
>>>>>> tag registered in the global tree as stated in the= draft "RFC 6809
>>>>>> [1] provides that addresses of intermediaries can = be communicated as
>>>>>> a value of an associated feature-capability indica= tor so it would be
>>>>>> appropriate to define feature capability indicator= s as part of the
>>>>>> global tree to communicate the GRUU of the interme= diary and hence
>>>>>> this is outside the scope of this document."&= nbsp; - RFC 6809 states " If
>>>>>> additional data about a supported feature needs to= be conveyed, such
>>>>>> as the address of the SIP entity that indicated su= pport of the
>>>>>> feature, then the feature definition needs to defi= ne a way to convey
>>>>>> that information as a value of the associated feat= ure-capability
>>>>>> indicator." However I think the SIP specific = capability indicators
>>>>>> such as methods, extensions and events should appr= opriately be
>>>>>> registered in the SIP tree not as proprietary indi= cator
>>>>> s in the global tree.
>>>>>
>>>>> So you have defined a sip tree feature tag that is onl= y useful in
>>>>> conjunction with another feature tag from the global t= ree.
>>>>> And the description of this feature tag doesn't even m= ention that.
>>>>>
>>>>> And this all implies a completely non-standard call mo= del - doing
>>>>> conferencing in a way inconsistent with RFC 4579.
>>>>>
>>>>> ISTM that if 4579 doesn't work for you then you should= be back
>>>>> proposing extensions/revisions to it.
>>>>>
>>>>>> If there is a conference bridge in the signaling p= ath, then I would
>>>>>> expect it to be the UAC.
>>>>>>
>>>>>> [AA] Although a "standard" way to invoke= a conference is to send a
>>>>>> REFER to the other UAs to invite them to the confe= rence focus,  in
>>>>>> many deployments a scenario exists where a call in= volves an IP-PBX
>>>>>> or Telephony Application Server (TAS) that can act= as a focus for
>>>>>> the conference. A participant of a call can then c= reate a conference
>>>>>> by sending a REFER request in dialog to the IP-PBX= or TAS to use
>>>>>> 3PCC to Invite other users to a conference. Reason= s for this are 1.
>>>>>> Not all UAs support REFER,
>>>>>
>>>>> So you are saying the intermediary isn't a focus (its = a B2BUA), but
>>>>> it *could become* a focus.
>>>>>
>>>>> The concept that a dialog may contain intermediaries t= hat can be
>>>>> addressed to do stuff is not part of any sip standard = that I am aware
>>>>> of. I don't care too much as long as the "stuff&q= uot; is application stuff
>>>>> that is outside the scope of sip. But when it is alter= native ways to
>>>>> do stuff that sip supports, then I get upset.
>>>>>
>>>>>> 2. Many SBCs reject REFER requests going outside d= omains because of
>>>>>> the potential for charging fraud (referring to a p= remium rate number
>>>>>> etc) 3. A User receiving a REFER and then using an= INVITE to join
>>>>>> the conference may be charged for initiating = the call when the
>>>>>> scenario is that the initiator of the conference s= hould be charged.
>>>>>> 4. No need to obtain and distribute conference URI= s.
>>>>>> Problem is how to achieve the same behavior withou= t dialog reuse
>>>>>> which has been deprecated by RFC 6665?
>>>>>
>>>>> Then maybe the problem needs to be brought up, and a s= tandard
>>>>> solution proposed, rather than simply enabling a propr= ietary mechanism.
>>>>>
>>>>>> As another example, consider section 5.1:
>>>>>>
>>>>>>        &nb= sp;    Descrition:
>>>>>>        &nb= sp;    This Feature-capability indicator indicates that the = intermediary
>>>>>>        &nb= sp;    supports audio as a streaming media type.
>>>>>> ...
>>>>>>        &nb= sp;       Examples of typical use: An IP PBX = indicating that it is
>>>>>>        &nb= sp;       capable of accepting and initiating= sessions with audio as a
>>>>>>        &nb= sp;       streaming media type.
>>>>>>
>>>>>> This definition *implies* an assumption about the = working
>>>>>> environment
>>>>>> - one that AFAIK is new. It implies that you need = to know that
>>>>>> intermediaries support a media type before you can= use it. Would it
>>>>>> be bad if there were no intermediaries, and so non= e indicated this?
>>>>>> What if some intermediary *did* indicate support, = but some other
>>>>>> doesn't, but doesn't indicate that it doesn't?
>>>>>>
>>>>>> Bottom line: how would the presence or absence of = this feature tag
>>>>>> affect subsequent usage?
>>>>>>
>>>>>> [AA] The absence of the streaming types does not i= ndicate that the
>>>>>> intermediary does not support the media type and S= DP offer answer
>>>>>> will ultimately determine what can or cannot be us= ed if another
>>>>>> session is initiated involving the intermediary. H= owever the
>>>>>> presence of the media type in a Feature-caps heade= r field does
>>>>>> explictly confirm that the intermediary does suppo= rt the media type
>>>>>> and in the scenario where a UA has a choice of mul= tiple
>>>>>> intermediaries it could use for a conference it mi= ght choose to use
>>>>>> the one that explicitly indicates it supports the = media types the UA wants to use.
>>>>>
>>>>> So the UA will be able to discover that *some* interme= diary supports
>>>>> media it is interested in. And it can tell that *some*= intermediary
>>>>> says it is a focus. It doesn't know if they are the sa= me intermediary.
>>>>>
>>>>> And then via some other feature tag it obtains the URI= of *some*
>>>>> intermediary on the signaling path. Or maybe it gets m= ore than one of
>>>>> these.
>>>>>
>>>>> It then makes a leap of faith and conflates all those = things, to
>>>>> determine that the URI identifies a focus that support= s this media type.
>>>>>
>>>>> Even then, exactly what does that mean? It may or may = not mean that
>>>>> it supports mixing that media type in a conference. >>>>>
>>>>>> As I stated already I don't care that much about t= hese streaming
>>>>>> media types.
>>>>>
>>>>>> I could go on, but this is enough for now.
>>>>>>
>>>>>> [AA] My motivation for this is that currently 3GPP= are updating
>>>>>> their specifications to use RFC 6665 instead of RF= C 3265.
>>>>>
>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and = REFER with
>>>>>> intermediaries accepting the REFER or SUBSCRIBE re= quest rather than
>>>>>> forwarding it all the way to the remote UA.
>>>>>
>>>>> And 6665 deprecates dial reuse in most of those cases.=
>>>>> Without dialog reuse, the intermediaries don't get an = opportunity to
>>>>> intercept those.
>>>>>
>>>>>> In order to know that an intermediary supports the= target dialog
>>>>>> mechanism  needed for a REFER request sent ou= tside the dialog to
>>>>>> work we need sip.extensions as a feature-capabilit= y indicator. In
>>>>>> order to know that the needed event package is sup= ported by the
>>>>>> intermediary so we can SUBSCROBE outside the dialo= g to an
>>>>>> intermediary we need sip.events as a feature-capab= ility indicator.
>>>>>
>>>>> Then I think you should be back here with a problem st= atement and a
>>>>> request for how to get sip to solve it.
>>>>>
>>>>> And you should touch base with Christer on this. He ma= y have a
>>>>> different opinion on the relevance of feature-caps as = a solution.
>>>>>
>>>>>         Thanks= ,
>>>>>         Paul >>>>>
>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote:
>>>>>>> Adam, Paul, Richard, Gonzalo
>>>>>>>
>>>>>>> I have submitted a new draft to sipcore  = to register a number of
>>>>>>> feature capability indicators in the SIP tree = (based upon some of
>>>>>>> the existing SIP media feature tags). The draf= t can be found at:
>>>>>>>
>>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00.<= br> >>>>>>> txt
>>>>>>>
>>>>>>> Since there will not be a sipcore session at I= ETF#88  can we have
>>>>>>> an offline discussion on how to progress this = draft (which
>>>>>>> hopefully is fairly straightforward as it just= registers feature
>>>>>>> capabilities indicators with IANA). I wouldn't= want to have to wait
>>>>>>> until March next year for a decision on progre= ssing this.
>>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>> ----------------------------------------------= ---------------------
>>>>>>> -
>>>>>>> - This transmission (including any attachments= ) may contain
>>>>>>> confidential information, privileged material = (including material
>>>>>>> protected by the solicitor-client or other app= licable privileges),
>>>>>>> or constitute non-public information. Any use = of this information
>>>>>>> by anyone other than the intended recipient is= prohibited. If you
>>>>>>> have received this transmission in error, plea= se immediately reply
>>>>>>> to the sender and delete this information from= your system. Use,
>>>>>>> dissemination, distribution, or reproduction o= f this transmission
>>>>>>> by unintended recipients is not authorized and= may be unlawful.
>>>>>>
>>>>>> --------------------------------------------------= ------------------
>>>>>> - This transmission (including any attachments) ma= y contain
>>>>>> confidential information, privileged material (inc= luding material
>>>>>> protected by the solicitor-client or other applica= ble privileges),
>>>>>> or constitute non-public information. Any use of t= his information by
>>>>>> anyone other than the intended recipient is prohib= ited. If you have
>>>>>> received this transmission in error, please immedi= ately reply to the
>>>>>> sender and delete this information from your syste= m. Use,
>>>>>> dissemination, distribution, or reproduction of th= is transmission by
>>>>>> unintended recipients is not authorized and may be= unlawful.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ----------------------------------------------------------= -----------
>>>> This transmission (including any attachments) may contain = confidential information, privileged material (including material protected= by the solicitor-client or other applicable privileges), or constitute non= -public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>>
>>>>
>>>
>>> --------------------------------------------------------------= -------
>>> This transmission (including any attachments) may contain conf= idential information, privileged material (including material protected by = the solicitor-client or other applicable privileges), or constitute non-pub= lic information. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>
>>>
>>
>> ------------------------------------------------------------------= ---
>> This transmission (including any attachments) may contain confiden= tial information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute non-public = information. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>
>>
>
> ---------------------------------------------------------------------<= br> > This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the soli= citor-client or other applicable privileges), or constitute non-public info= rmation. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>
>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
--_000_7594FB04B1934943A5C02806D1A2204B1C4F7024ESESSMB209erics_-- From pkyzivat@alum.mit.edu Fri Oct 25 11:33:47 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5A311E81B3 for ; Fri, 25 Oct 2013 11:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.594 X-Spam-Level: X-Spam-Status: No, score=0.594 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPXKqgl8EEyD for ; Fri, 25 Oct 2013 11:33:42 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 5F99011E81CB for ; Fri, 25 Oct 2013 11:33:42 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta02.westchester.pa.mail.comcast.net with comcast id hQ0s1m0020mv7h051WZhmD; Fri, 25 Oct 2013 18:33:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id hWZh1m00U3ZTu2S3XWZheh; Fri, 25 Oct 2013 18:33:41 +0000 Message-ID: <526AB985.2010809@alum.mit.edu> Date: Fri, 25 Oct 2013 14:33:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: SIPCORE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382726021; bh=PRGXTPWL4MaqkQE83hhknIJG8pbg0f8WSKfhgsVKQao=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oa+E/bdaJUsLsKPtYkHRvj6rikyOBddA7B7IzmEWZf4U0kC/AgA23hkVLV3+8/Swj hhR8uVrHWlOJuz1/3AOOaB4nJmTUP0lvOP9BcQnzZT5NP2sXeUTMl8oHSkatWSQyEm Qn8X8zVVZKedfm1WkjIY4Qds39C/paWX2VB8/LU27r8wZ81wmDdzt2xoNW4zb9hgrK 9wZzPV0/PYDUy3Sao32lVXb7mm/Rx493XXOjaZp+IzG1bCI2Zf56vsMEfsN1vzT6dr ri08l6byNTRJjiqDBscLTaeCCPb0oRtj5nRU5NKeJBnzzxvpmc/f4YDyc/6deE1qp8 5p7U/RqE93Zmg== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 18:33:47 -0000 (We've been having a side conversation on this draft, but I want it to continue on the sipcore list. So the following is a repost of a reply I previously sent to Andrew.) Andrew, (I see this is still on the private thread. I'll reply here, but this exchange should probably be reposted to the sipcore list as part of the public discussion of the draft.) On 10/24/13 10:41 PM, Andrew Allen wrote: > > Paul > > I am happy to do a revision with more details on the semantics of the capability indicators. However I don't think it should be held to a very much higher bar than the details in RFC 3840 and the other media feature tag RFCs regarding the meaning of those tags. Keep in mind that the driving force for the definition of feature tags in 3840 was in support of callerprefs (3841). So the context for the use of feature tags was that they would be placed on Contacts in REGISTER requests. So you can interpret the definitions in that context: that a request sent to an AOR using callerprefs can affect the choice of which device the request goes to according to the capabilities it wants. In that context audio, video, isfocus all make sense. Their use on Contacts in dialogs was derivative to that: because callerpref support is optional, there is no guarantee that the device you reach via callerprefs will have the capabilities you requested. So the values in the contact help confirm what you got. Of course they have since been used other ways. And the descriptions of them don't necessarily reflect that. IMO that is a defect due to the evolution of use. I'm looking for the same sort of context for use with the feature-caps. In private discussion you indicated to me that you expected the feature caps to be grouped - with one of them giving the URI of the device that the other tags apply to. I guess this would end up looking something like: Feature-Caps: *;g.uri="sip:foo@example.com";audio Feature-Caps: *;g.uri="sip:bar@example.com";audio;video;isfocus Feature-Caps: *;g.uri="sip:baz@example.com";text (I'm making up g.uri for the example.) And then presumably somebody on the signaling path will "shop" in the feature caps for the capabilities it wants, and then send a request to that URI, with the expectation that the UA responding will have those capabilities. > The semantics should be no different than those of the corresponding existing media feature tag if it is present in the Contact header. Note that 6809 says: When a SIP entity receives a SIP request, or response, that contains one or more Feature-Caps header fields, the feature-capability indicators in the header field inform the entity about the features and capabilities supported by entities in the SIP message signaling path. The procedure by which features and capabilities are invoked are outside the scope of this specification and MUST be described by individual feature-capability indicator specifications. A Feature-Caps header field value cannot convey the address of the SIP entity that inserted the Feature-Caps header field. If additional data about a supported feature needs to be conveyed, such as the address of the SIP entity that indicated support of the feature, then the feature definition needs to define a way to convey that information as a value of the associated feature-capability indicator. This was discussed at length while that RFC was under consideration. Yet the definitions of the tags in *this* draft don't specify that. > The registration templates currently reference the RFC 3840 and the other RFCs that define the other media feature tags that correspond to these feature capability indicators. And those definitions were written to be understood in the context of 3840/3841. They make sense in that context, but not in *this* context. Thanks, Paul > But if more explicit detail is required then I can add some more text or alternatively remove the less important ones if they are going to become rat holes. The ones I regard as really important and urgent are sip.methods, sip.extensions and sip.events the meaning of which I think should be quite clear. > > Andrew > > ----- Original Message ----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time > To: Andrew Allen; Gonzalo.Camarillo@ericsson.com > Cc: rlb@ipv.sx ; adam@nostrum.com ; christer.holmberg@ericsson.com ; mary.ietf.barnes@gmail.com ; Paul Kyzivat > Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators > > On 10/24/13 4:07 PM, Andrew Allen wrote: >> >> Paul >> >> Ok >> >> So we are basically where I thought we were at when I submitted the draft. >> >> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who indicates interest) can have some offline discussion in Vancouver on whether and how to progress this. > > As I indicated again on the sipcore list, I found the that the draft > didn't explain nearly enough to allow meaningful use of these. > I know you replied, and I will continue the conversation there. > But I will be opposed to these until and unless the draft (and notably > the descriptions of the tags) are clear about how one could figure out > what can do in the presence of the tags that one couldn't do without > them. AND, that the behavior that suggests doesn't "break" sip. (E.g., > by advocating a new and incompatible way to do something.) > > We can continue this on the sipcore list. > > Thanks, > Paul > >> Andrew >> >> ----- Original Message ----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >> To: Andrew Allen; Gonzalo Camarillo >> Cc: Richard Barnes (rlb@ipv.sx) ; Adam Roach (adam@nostrum.com) ; Christer Holmberg (christer.holmberg@ericsson.com) ; Mary Barnes (mary.ietf.barnes@gmail.com) >> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators >> >> On 10/24/13 2:17 PM, Andrew Allen wrote: >>> Paul >>> >>> That is fine. Although Mary in her reply to me seemed to indicate maybe there was a possibility to use some of the DISPATCH spare time for a SIPCORE session for this. Is that a possibility? >>> >>> I already replied to your post >> >> I discussed that with Adam. We decided we can't set a precedent to spin >> up a session to discuss a draft that hasn't had substantial (any) list >> discussion. >> >> But list discussion is always welcome. >> >> Sorry, >> Paul >> >>> Andrew >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, October 24, 2013 1:31 PM >>> To: Andrew Allen; Gonzalo Camarillo >>> Cc: Richard Barnes (rlb@ipv.sx); Adam Roach (adam@nostrum.com); Christer Holmberg (christer.holmberg@ericsson.com) >>> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators >>> >>> Andrew, >>> >>> I spoke with Mary about it, and we concluded that dispatch isn't right for this. (In addition to being clearly sipcore, it didn't meet the deadline for dispatch.) I was wrong to encourage you that way. >>> >>> So no official live discussion in Vancouver. (But informal discussion >>> fine.) >>> >>> I'll resend my private comments to the sipcore list to kickstart some discussion there. >>> >>> Thanks, >>> Paul >>> >>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>> I just emailed Mary asking for agenda time. Should I cancel that request? >>>> >>>> -----Original Message----- >>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>> Sent: Thursday, October 24, 2013 1:00 PM >>>> To: Paul Kyzivat >>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx); Adam Roach >>>> (adam@nostrum.com); Christer Holmberg (christer.holmberg@ericsson.com) >>>> Subject: Re: New sipcore draft submission >>>> draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> Hi Paul, >>>> >>>> given that you think this belongs to SIPCORE, I do not see the need to run it through DISPATCH. Please, start technical discussions on the draft on the SIPCORE list. >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>> Paul >>>>>> >>>>>> Thanks for reviewing the draft already and giving me early feedback. >>>>>> >>>>>> My responses below inline (prepended with [AA). >>>>>> >>>>>> Can I ask the ADs to determine ASAP if this needs to go to DISPATCH >>>>>> first or not. As outlined below my view is that it is unnecessary >>>>>> for every little thing to go to DISPATCH as this just creates >>>>>> additional delay and overhead. If it is to be discussed in DISPATCH >>>>>> then I definitely would want agenda time atIETF#88 for this. >>>>> >>>>> Having now seen Andrew's responses to my initial questions, I think >>>>> this >>>>> *needs* to be carefully considered by sipcore. IMO this has the >>>>> potential to create a dialect of sip that is incompatible with normal >>>>> usage. (Maybe IMS has already done that. But this will make it >>>>> worse.) >>>>> >>>>> But if there is a desire to discuss it publicly in Vancouver then >>>>> dispatch is the opportunity and so some discussion on the dispatch >>>>> list in advance of that would be appropriate. >>>>> >>>>> I'll defer to the ADs on this. >>>>> >>>>> More inline. >>>>> >>>>>> Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx); Gonzalo Camarillo >>>>>> (Gonzalo.Camarillo@ericsson.com); Adam Roach (adam@nostrum.com) >>>>>> Subject: Re: New sipcore draft submission >>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>> >>>>>> Andrew, >>>>>> >>>>>> On a legalistic note, its questionable to me whether this kind of >>>>>> action falls within the scope of sipcore. OTOH, among existing wgs, >>>>>> sipcore is probably the best suited to discuss the proposal. We >>>>>> could take it to DISPATCH. I think DISPATCH has extra time in its >>>>>> agenda for Vancouver, so that might be one option for you. But then >>>>>> I don't know where dispatch would dispatch it. It may be that AD >>>>>> sponsored is the best way to go. >>>>>> >>>>>> [AA] It seemed to me that sipcore was the right place. This draft >>>>>> registers feature-capability indicators in a registry that was >>>>>> created by a sipcore RFC (RFC 6809). You could in my view make an >>>>>> argument that this should even have been done as part of RFC 6809. >>>>> >>>>> If this was just a matter of registering some new feature caps that >>>>> were not controversial, then I don't think sipcore needs to be involved. >>>>> >>>>> But as I mentioned above, I do consider these controversial. >>>>> >>>>>> Discussing it now on the dispatch list would be a good start toward >>>>>> discussing it at the dispatch session. >>>>>> >>>>>> [AA] Can I ask the ADs to determine if this needs to go to DISPATCH >>>>>> first or not. My view is that it is unnecessary for every little >>>>>> thing to go to DISPATCH as this just creates additional delay and overhead. >>>>>> This just registers some indicators in an existing IANA registry and >>>>>> is not (or should not be IMHO) a major project. >>>>> >>>>> To me this is a matter of whether you want to be opportunistic. >>>>> If this went to dispatch I would now recommend that it be dispatched >>>>> to sipcore. So its a matter of whether you want to talk about it in >>>>> the dispatch meeting. >>>>> >>>>>> Regarding substance, this draft troubles me. It takes feature-caps >>>>>> in exactly the direction that I found most concerning about the >>>>>> mechanism in the first place. >>>>>> >>>>>> Your draft partitions the existing media feature tags into two sets >>>>>> - those that would be useful as feature-capability-indicators, and >>>>>> those that aren't. But I see no explanation of the criteria used to >>>>>> make this distinction, nor can I think of one. >>>>>> >>>>>> [AA] I based this decision on the following criteria: If a feature >>>>>> tag was potentially at all useful for an intermediary to indicate it >>>>>> then include it in the registry. The ones not included are either >>>>>> directly associated with the user (intermediaries are not directly >>>>>> associated with the user) or would only ever have one value (e.g >>>>>> automata). I am not sure that every feature-capability indicator >>>>>> proposed to be registered is actually useful but then I don't think >>>>>> every media feature tag registered by RFC 3840 is either (I doubt >>>>>> very much if there are implementation using the sip.application or >>>>>> sip.control feature tags). I don't think RFC 3840 goes into a lot of >>>>>> details justifying of ever registered media feature tag and >>>>>> specifying the details of how they would be used either. I am >>>>>> willing to remove any feature-capability indicators that are >>>>>> controversial except that I think we definitely need sip.extensions, sip.methods and sip.events. >>>>>> There is a significant overhead to writing an >>>>> d progressing internet drafts so my view is lets register all that >>>>> might be remotely useful in the same document. >>>>> >>>>> The judgement of "useful" is reasonable. But I still can't discern >>>>> what the use is from the iana registration descriptions. >>>>> >>>>>> For the ones that you have requested feature capability indicators, >>>>>> I cannot figure out what using them would mean. For example, when I >>>>>> see isFocus on a Contact header I know I am in a conference, and >>>>>> that I can subscribe to the conference event package at the contact >>>>>> URI. If I see isFocus in a Feature-Caps header, what does it mean? >>>>>> What can I do once I know this? >>>>>> >>>>>> Section 5.14 of this draft says: >>>>>> >>>>>> This Feature-capability indicator indicates that the intermediary >>>>>> is a conference server, also known as a focus, and is capable of >>>>>> mixing together the media for all calls to the same URI. >>>>>> ... >>>>>> Examples of typical use: A conference bridge indicating >>>>>> that it >>>>>> is a conference bridge and is capable of acting as a >>>>>> conference >>>>>> focus for this session. >>>>>> >>>>>> [AA] the presence of isfocus in a Feature-Caps header field means >>>>>> that a UA can initiate a conference by sending a REFER request to >>>>>> the intermediary to invite another user and create a multi user >>>>>> conference from the 1-1 session. >>>>>> >>>>>> Note that Feature-Caps doesn't indicate which entity has this >>>>>> capability, only that something does. And since this would >>>>>> presumably only be used if it wasn't the UAC of the request, sending >>>>>> a subscribe to the contact address of the UAC wouldn't make sense. >>>>>> >>>>>> [AA] Yes the GRUU of the intermediary would be needed but I consider >>>>>> this application specific and so this would be included in a feature >>>>>> tag registered in the global tree as stated in the draft "RFC 6809 >>>>>> [1] provides that addresses of intermediaries can be communicated as >>>>>> a value of an associated feature-capability indicator so it would be >>>>>> appropriate to define feature capability indicators as part of the >>>>>> global tree to communicate the GRUU of the intermediary and hence >>>>>> this is outside the scope of this document." - RFC 6809 states " If >>>>>> additional data about a supported feature needs to be conveyed, such >>>>>> as the address of the SIP entity that indicated support of the >>>>>> feature, then the feature definition needs to define a way to convey >>>>>> that information as a value of the associated feature-capability >>>>>> indicator." However I think the SIP specific capability indicators >>>>>> such as methods, extensions and events should appropriately be >>>>>> registered in the SIP tree not as proprietary indicator >>>>> s in the global tree. >>>>> >>>>> So you have defined a sip tree feature tag that is only useful in >>>>> conjunction with another feature tag from the global tree. >>>>> And the description of this feature tag doesn't even mention that. >>>>> >>>>> And this all implies a completely non-standard call model - doing >>>>> conferencing in a way inconsistent with RFC 4579. >>>>> >>>>> ISTM that if 4579 doesn't work for you then you should be back >>>>> proposing extensions/revisions to it. >>>>> >>>>>> If there is a conference bridge in the signaling path, then I would >>>>>> expect it to be the UAC. >>>>>> >>>>>> [AA] Although a "standard" way to invoke a conference is to send a >>>>>> REFER to the other UAs to invite them to the conference focus, in >>>>>> many deployments a scenario exists where a call involves an IP-PBX >>>>>> or Telephony Application Server (TAS) that can act as a focus for >>>>>> the conference. A participant of a call can then create a conference >>>>>> by sending a REFER request in dialog to the IP-PBX or TAS to use >>>>>> 3PCC to Invite other users to a conference. Reasons for this are 1. >>>>>> Not all UAs support REFER, >>>>> >>>>> So you are saying the intermediary isn't a focus (its a B2BUA), but >>>>> it *could become* a focus. >>>>> >>>>> The concept that a dialog may contain intermediaries that can be >>>>> addressed to do stuff is not part of any sip standard that I am aware >>>>> of. I don't care too much as long as the "stuff" is application stuff >>>>> that is outside the scope of sip. But when it is alternative ways to >>>>> do stuff that sip supports, then I get upset. >>>>> >>>>>> 2. Many SBCs reject REFER requests going outside domains because of >>>>>> the potential for charging fraud (referring to a premium rate number >>>>>> etc) 3. A User receiving a REFER and then using an INVITE to join >>>>>> the conference may be charged for initiating the call when the >>>>>> scenario is that the initiator of the conference should be charged. >>>>>> 4. No need to obtain and distribute conference URIs. >>>>>> Problem is how to achieve the same behavior without dialog reuse >>>>>> which has been deprecated by RFC 6665? >>>>> >>>>> Then maybe the problem needs to be brought up, and a standard >>>>> solution proposed, rather than simply enabling a proprietary mechanism. >>>>> >>>>>> As another example, consider section 5.1: >>>>>> >>>>>> Descrition: >>>>>> This Feature-capability indicator indicates that the intermediary >>>>>> supports audio as a streaming media type. >>>>>> ... >>>>>> Examples of typical use: An IP PBX indicating that it is >>>>>> capable of accepting and initiating sessions with audio as a >>>>>> streaming media type. >>>>>> >>>>>> This definition *implies* an assumption about the working >>>>>> environment >>>>>> - one that AFAIK is new. It implies that you need to know that >>>>>> intermediaries support a media type before you can use it. Would it >>>>>> be bad if there were no intermediaries, and so none indicated this? >>>>>> What if some intermediary *did* indicate support, but some other >>>>>> doesn't, but doesn't indicate that it doesn't? >>>>>> >>>>>> Bottom line: how would the presence or absence of this feature tag >>>>>> affect subsequent usage? >>>>>> >>>>>> [AA] The absence of the streaming types does not indicate that the >>>>>> intermediary does not support the media type and SDP offer answer >>>>>> will ultimately determine what can or cannot be used if another >>>>>> session is initiated involving the intermediary. However the >>>>>> presence of the media type in a Feature-caps header field does >>>>>> explictly confirm that the intermediary does support the media type >>>>>> and in the scenario where a UA has a choice of multiple >>>>>> intermediaries it could use for a conference it might choose to use >>>>>> the one that explicitly indicates it supports the media types the UA wants to use. >>>>> >>>>> So the UA will be able to discover that *some* intermediary supports >>>>> media it is interested in. And it can tell that *some* intermediary >>>>> says it is a focus. It doesn't know if they are the same intermediary. >>>>> >>>>> And then via some other feature tag it obtains the URI of *some* >>>>> intermediary on the signaling path. Or maybe it gets more than one of >>>>> these. >>>>> >>>>> It then makes a leap of faith and conflates all those things, to >>>>> determine that the URI identifies a focus that supports this media type. >>>>> >>>>> Even then, exactly what does that mean? It may or may not mean that >>>>> it supports mixing that media type in a conference. >>>>> >>>>>> As I stated already I don't care that much about these streaming >>>>>> media types. >>>>> >>>>>> I could go on, but this is enough for now. >>>>>> >>>>>> [AA] My motivation for this is that currently 3GPP are updating >>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>> >>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with >>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather than >>>>>> forwarding it all the way to the remote UA. >>>>> >>>>> And 6665 deprecates dial reuse in most of those cases. >>>>> Without dialog reuse, the intermediaries don't get an opportunity to >>>>> intercept those. >>>>> >>>>>> In order to know that an intermediary supports the target dialog >>>>>> mechanism needed for a REFER request sent outside the dialog to >>>>>> work we need sip.extensions as a feature-capability indicator. In >>>>>> order to know that the needed event package is supported by the >>>>>> intermediary so we can SUBSCROBE outside the dialog to an >>>>>> intermediary we need sip.events as a feature-capability indicator. >>>>> >>>>> Then I think you should be back here with a problem statement and a >>>>> request for how to get sip to solve it. >>>>> >>>>> And you should touch base with Christer on this. He may have a >>>>> different opinion on the relevance of feature-caps as a solution. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>> >>>>>>> I have submitted a new draft to sipcore to register a number of >>>>>>> feature capability indicators in the SIP tree (based upon some of >>>>>>> the existing SIP media feature tags). The draft can be found at: >>>>>>> >>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00. >>>>>>> txt >>>>>>> >>>>>>> Since there will not be a sipcore session at IETF#88 can we have >>>>>>> an offline discussion on how to progress this draft (which >>>>>>> hopefully is fairly straightforward as it just registers feature >>>>>>> capabilities indicators with IANA). I wouldn't want to have to wait >>>>>>> until March next year for a decision on progressing this. >>>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> ------------------------------------------------------------------- >>>>>>> - >>>>>>> - This transmission (including any attachments) may contain >>>>>>> confidential information, privileged material (including material >>>>>>> protected by the solicitor-client or other applicable privileges), >>>>>>> or constitute non-public information. Any use of this information >>>>>>> by anyone other than the intended recipient is prohibited. If you >>>>>>> have received this transmission in error, please immediately reply >>>>>>> to the sender and delete this information from your system. Use, >>>>>>> dissemination, distribution, or reproduction of this transmission >>>>>>> by unintended recipients is not authorized and may be unlawful. >>>>>> >>>>>> -------------------------------------------------------------------- >>>>>> - This transmission (including any attachments) may contain >>>>>> confidential information, privileged material (including material >>>>>> protected by the solicitor-client or other applicable privileges), >>>>>> or constitute non-public information. Any use of this information by >>>>>> anyone other than the intended recipient is prohibited. If you have >>>>>> received this transmission in error, please immediately reply to the >>>>>> sender and delete this information from your system. Use, >>>>>> dissemination, distribution, or reproduction of this transmission by >>>>>> unintended recipients is not authorized and may be unlawful. >>>>>> >>>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>> >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > > From pkyzivat@alum.mit.edu Fri Oct 25 11:39:16 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C486A21F9E62 for ; Fri, 25 Oct 2013 11:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.604 X-Spam-Level: X-Spam-Status: No, score=0.604 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q61gBdlXRjGf for ; Fri, 25 Oct 2013 11:39:12 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 31FC121F9B85 for ; Fri, 25 Oct 2013 11:38:47 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta10.westchester.pa.mail.comcast.net with comcast id hVLJ1m0080cZkys5AWedKj; Fri, 25 Oct 2013 18:38:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id hWec1m00X3ZTu2S3WWedgc; Fri, 25 Oct 2013 18:38:37 +0000 Message-ID: <526ABAAC.1000304@alum.mit.edu> Date: Fri, 25 Oct 2013 14:38:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Andrew Allen , SIPCORE References: <526A7ADF.8010106@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382726317; bh=YKS6VVRBScEhmE70v7tketbI5V7hePd4j/4pAk7dN08=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=G+CTFiLylNX9SPTKu+vi9evJUVemhfoSkP4EQyXHatcAFl/JlREyNOM5026qb5+1B DATfhy1k5ED0ap2qZs4P7rIMoMwnakhaBthKzionGCsUSkyyA4shlNCHUOzoPI/Ebd 5gltvB4wYlUxitOcJxZd0B6MoW8JXWh6GWU9Xe8zygwoiALCaQa7Buof0IGaijB4JI Ounn3oGIgZUPRTtazlTNgqNkQ47B8YlU775JONx1/NtqAo9tfQe0svfkmLyqSE9l0U rm5YxMIX7c04jHQk8aVMu+qe0LhA3buTAf1LpKM8mpjePYBLWqlehuhaUY4pNes6XN ynDQYuC4aIwog== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 18:39:17 -0000 On 10/25/13 1:52 PM, Andrew Allen wrote: > > Paul > > The next revisions will contain more details on what each FCI (as Christer now calls them means). > > If some are not well understood I will remove them from the draft (i.e. drop the rat holes) > > I think my email exchange with Christer clarifies the other points. > > Does this represent in principle a way forward? Maybe. We'll have to see how it goes. The challenge is, I think, that you want to bring in a bunch of the 3840 feature tags, and have them mean something akin to what they do as feature tags when used as FCIs. But there needs to be some way to describe what *each* one means. It's not immediately clear to me how to do that. > I think we need to conclude on the list. Can you respond to my response? I'll respond further to other messages in the thread. Thanks, Paul > Andrew > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, October 25, 2013 10:06 AM > To: Andrew Allen; Gonzalo.Camarillo@ericsson.com > Cc: rlb@ipv.sx; adam@nostrum.com; christer.holmberg@ericsson.com; mary.ietf.barnes@gmail.com > Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators > > Andrew, > > (I see this is still on the private thread. I'll reply here, but this exchange should probably be reposted to the sipcore list as part of the public discussion of the draft.) > > On 10/24/13 10:41 PM, Andrew Allen wrote: >> >> Paul >> >> I am happy to do a revision with more details on the semantics of the capability indicators. However I don't think it should be held to a very much higher bar than the details in RFC 3840 and the other media feature tag RFCs regarding the meaning of those tags. > > Keep in mind that the driving force for the definition of feature tags in 3840 was in support of callerprefs (3841). So the context for the use of feature tags was that they would be placed on Contacts in REGISTER requests. So you can interpret the definitions in that context: that a request sent to an AOR using callerprefs can affect the choice of which device the request goes to according to the capabilities it wants. In that context audio, video, isfocus all make sense. > > Their use on Contacts in dialogs was derivative to that: because callerpref support is optional, there is no guarantee that the device you reach via callerprefs will have the capabilities you requested. So the values in the contact help confirm what you got. > > Of course they have since been used other ways. And the descriptions of them don't necessarily reflect that. IMO that is a defect due to the evolution of use. > > I'm looking for the same sort of context for use with the feature-caps. > > In private discussion you indicated to me that you expected the feature caps to be grouped - with one of them giving the URI of the device that the other tags apply to. I guess this would end up looking something like: > > Feature-Caps: *;g.uri="sip:foo@example.com";audio > Feature-Caps: *;g.uri="sip:bar@example.com";audio;video;isfocus > Feature-Caps: *;g.uri="sip:baz@example.com";text > > (I'm making up g.uri for the example.) > > And then presumably somebody on the signaling path will "shop" in the feature caps for the capabilities it wants, and then send a request to that URI, with the expectation that the UA responding will have those capabilities. > >> The semantics should be no different than those of the corresponding existing media feature tag if it is present in the Contact header. > > Note that 6809 says: > > When a SIP entity receives a SIP request, or response, that contains > one or more Feature-Caps header fields, the feature-capability > indicators in the header field inform the entity about the features > and capabilities supported by entities in the SIP message signaling > path. The procedure by which features and capabilities are invoked > are outside the scope of this specification and MUST be described by > individual feature-capability indicator specifications. > > A Feature-Caps header field value cannot convey the address of the > SIP entity that inserted the Feature-Caps header field. If > additional data about a supported feature needs to be conveyed, such > as the address of the SIP entity that indicated support of the > feature, then the feature definition needs to define a way to convey > that information as a value of the associated feature-capability > indicator. > > This was discussed at length while that RFC was under consideration. Yet the definitions of the tags in *this* draft don't specify that. > >> The registration templates currently reference the RFC 3840 and the other RFCs that define the other media feature tags that correspond to these feature capability indicators. > > And those definitions were written to be understood in the context of 3840/3841. They make sense in that context, but not in *this* context. > > Thanks, > Paul > >> But if more explicit detail is required then I can add some more text or alternatively remove the less important ones if they are going to become rat holes. The ones I regard as really important and urgent are sip.methods, sip.extensions and sip.events the meaning of which I think should be quite clear. >> >> Andrew >> >> ----- Original Message ----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com >> >> Cc: rlb@ipv.sx ; adam@nostrum.com ; >> christer.holmberg@ericsson.com ; >> mary.ietf.barnes@gmail.com ; Paul Kyzivat >> >> Subject: Re: New sipcore draft submission >> draft-allen-sipcore-sip-tree-cap-indicators >> >> On 10/24/13 4:07 PM, Andrew Allen wrote: >>> >>> Paul >>> >>> Ok >>> >>> So we are basically where I thought we were at when I submitted the draft. >>> >>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who indicates interest) can have some offline discussion in Vancouver on whether and how to progress this. >> >> As I indicated again on the sipcore list, I found the that the draft >> didn't explain nearly enough to allow meaningful use of these. >> I know you replied, and I will continue the conversation there. >> But I will be opposed to these until and unless the draft (and notably >> the descriptions of the tags) are clear about how one could figure out >> what can do in the presence of the tags that one couldn't do without >> them. AND, that the behavior that suggests doesn't "break" sip. (E.g., >> by advocating a new and incompatible way to do something.) >> >> We can continue this on the sipcore list. >> >> Thanks, >> Paul >> >>> Andrew >>> >>> ----- Original Message ----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >>> To: Andrew Allen; Gonzalo Camarillo >>> Cc: Richard Barnes (rlb@ipv.sx) ; Adam Roach >>> (adam@nostrum.com) ; Christer Holmberg >>> (christer.holmberg@ericsson.com) ; >>> Mary Barnes (mary.ietf.barnes@gmail.com) >>> Subject: Re: New sipcore draft submission >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> On 10/24/13 2:17 PM, Andrew Allen wrote: >>>> Paul >>>> >>>> That is fine. Although Mary in her reply to me seemed to indicate maybe there was a possibility to use some of the DISPATCH spare time for a SIPCORE session for this. Is that a possibility? >>>> >>>> I already replied to your post >>> >>> I discussed that with Adam. We decided we can't set a precedent to >>> spin up a session to discuss a draft that hasn't had substantial >>> (any) list discussion. >>> >>> But list discussion is always welcome. >>> >>> Sorry, >>> Paul >>> >>>> Andrew >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, October 24, 2013 1:31 PM >>>> To: Andrew Allen; Gonzalo Camarillo >>>> Cc: Richard Barnes (rlb@ipv.sx); Adam Roach (adam@nostrum.com); >>>> Christer Holmberg (christer.holmberg@ericsson.com) >>>> Subject: Re: New sipcore draft submission >>>> draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> Andrew, >>>> >>>> I spoke with Mary about it, and we concluded that dispatch isn't right for this. (In addition to being clearly sipcore, it didn't meet the deadline for dispatch.) I was wrong to encourage you that way. >>>> >>>> So no official live discussion in Vancouver. (But informal >>>> discussion >>>> fine.) >>>> >>>> I'll resend my private comments to the sipcore list to kickstart some discussion there. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>>> I just emailed Mary asking for agenda time. Should I cancel that request? >>>>> >>>>> -----Original Message----- >>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>> Sent: Thursday, October 24, 2013 1:00 PM >>>>> To: Paul Kyzivat >>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx); Adam Roach >>>>> (adam@nostrum.com); Christer Holmberg >>>>> (christer.holmberg@ericsson.com) >>>>> Subject: Re: New sipcore draft submission >>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>> >>>>> Hi Paul, >>>>> >>>>> given that you think this belongs to SIPCORE, I do not see the need to run it through DISPATCH. Please, start technical discussions on the draft on the SIPCORE list. >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>>> Paul >>>>>>> >>>>>>> Thanks for reviewing the draft already and giving me early feedback. >>>>>>> >>>>>>> My responses below inline (prepended with [AA). >>>>>>> >>>>>>> Can I ask the ADs to determine ASAP if this needs to go to >>>>>>> DISPATCH first or not. As outlined below my view is that it is >>>>>>> unnecessary for every little thing to go to DISPATCH as this just >>>>>>> creates additional delay and overhead. If it is to be discussed >>>>>>> in DISPATCH then I definitely would want agenda time atIETF#88 for this. >>>>>> >>>>>> Having now seen Andrew's responses to my initial questions, I >>>>>> think this >>>>>> *needs* to be carefully considered by sipcore. IMO this has the >>>>>> potential to create a dialect of sip that is incompatible with >>>>>> normal usage. (Maybe IMS has already done that. But this will make >>>>>> it >>>>>> worse.) >>>>>> >>>>>> But if there is a desire to discuss it publicly in Vancouver then >>>>>> dispatch is the opportunity and so some discussion on the dispatch >>>>>> list in advance of that would be appropriate. >>>>>> >>>>>> I'll defer to the ADs on this. >>>>>> >>>>>> More inline. >>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx); Gonzalo Camarillo >>>>>>> (Gonzalo.Camarillo@ericsson.com); Adam Roach (adam@nostrum.com) >>>>>>> Subject: Re: New sipcore draft submission >>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>> >>>>>>> Andrew, >>>>>>> >>>>>>> On a legalistic note, its questionable to me whether this kind of >>>>>>> action falls within the scope of sipcore. OTOH, among existing >>>>>>> wgs, sipcore is probably the best suited to discuss the proposal. >>>>>>> We could take it to DISPATCH. I think DISPATCH has extra time in >>>>>>> its agenda for Vancouver, so that might be one option for you. >>>>>>> But then I don't know where dispatch would dispatch it. It may be >>>>>>> that AD sponsored is the best way to go. >>>>>>> >>>>>>> [AA] It seemed to me that sipcore was the right place. This draft >>>>>>> registers feature-capability indicators in a registry that was >>>>>>> created by a sipcore RFC (RFC 6809). You could in my view make an >>>>>>> argument that this should even have been done as part of RFC 6809. >>>>>> >>>>>> If this was just a matter of registering some new feature caps >>>>>> that were not controversial, then I don't think sipcore needs to be involved. >>>>>> >>>>>> But as I mentioned above, I do consider these controversial. >>>>>> >>>>>>> Discussing it now on the dispatch list would be a good start >>>>>>> toward discussing it at the dispatch session. >>>>>>> >>>>>>> [AA] Can I ask the ADs to determine if this needs to go to >>>>>>> DISPATCH first or not. My view is that it is unnecessary for >>>>>>> every little thing to go to DISPATCH as this just creates additional delay and overhead. >>>>>>> This just registers some indicators in an existing IANA registry >>>>>>> and is not (or should not be IMHO) a major project. >>>>>> >>>>>> To me this is a matter of whether you want to be opportunistic. >>>>>> If this went to dispatch I would now recommend that it be >>>>>> dispatched to sipcore. So its a matter of whether you want to talk >>>>>> about it in the dispatch meeting. >>>>>> >>>>>>> Regarding substance, this draft troubles me. It takes >>>>>>> feature-caps in exactly the direction that I found most >>>>>>> concerning about the mechanism in the first place. >>>>>>> >>>>>>> Your draft partitions the existing media feature tags into two >>>>>>> sets >>>>>>> - those that would be useful as feature-capability-indicators, >>>>>>> and those that aren't. But I see no explanation of the criteria >>>>>>> used to make this distinction, nor can I think of one. >>>>>>> >>>>>>> [AA] I based this decision on the following criteria: If a >>>>>>> feature tag was potentially at all useful for an intermediary to >>>>>>> indicate it then include it in the registry. The ones not >>>>>>> included are either directly associated with the user >>>>>>> (intermediaries are not directly associated with the user) or >>>>>>> would only ever have one value (e.g automata). I am not sure >>>>>>> that every feature-capability indicator proposed to be registered >>>>>>> is actually useful but then I don't think every media feature tag >>>>>>> registered by RFC 3840 is either (I doubt very much if there are >>>>>>> implementation using the sip.application or sip.control feature >>>>>>> tags). I don't think RFC 3840 goes into a lot of details >>>>>>> justifying of ever registered media feature tag and specifying >>>>>>> the details of how they would be used either. I am willing to >>>>>>> remove any feature-capability indicators that are controversial except that I think we definitely need sip.extensions, sip.methods and sip.events. >>>>>>> There is a significant overhead to writing an >>>>>> d progressing internet drafts so my view is lets register all that >>>>>> might be remotely useful in the same document. >>>>>> >>>>>> The judgement of "useful" is reasonable. But I still can't discern >>>>>> what the use is from the iana registration descriptions. >>>>>> >>>>>>> For the ones that you have requested feature capability >>>>>>> indicators, I cannot figure out what using them would mean. For >>>>>>> example, when I see isFocus on a Contact header I know I am in a >>>>>>> conference, and that I can subscribe to the conference event >>>>>>> package at the contact URI. If I see isFocus in a Feature-Caps header, what does it mean? >>>>>>> What can I do once I know this? >>>>>>> >>>>>>> Section 5.14 of this draft says: >>>>>>> >>>>>>> This Feature-capability indicator indicates that the intermediary >>>>>>> is a conference server, also known as a focus, and is capable of >>>>>>> mixing together the media for all calls to the same URI. >>>>>>> ... >>>>>>> Examples of typical use: A conference bridge >>>>>>> indicating that it >>>>>>> is a conference bridge and is capable of acting as >>>>>>> a conference >>>>>>> focus for this session. >>>>>>> >>>>>>> [AA] the presence of isfocus in a Feature-Caps header field means >>>>>>> that a UA can initiate a conference by sending a REFER request to >>>>>>> the intermediary to invite another user and create a multi user >>>>>>> conference from the 1-1 session. >>>>>>> >>>>>>> Note that Feature-Caps doesn't indicate which entity has this >>>>>>> capability, only that something does. And since this would >>>>>>> presumably only be used if it wasn't the UAC of the request, >>>>>>> sending a subscribe to the contact address of the UAC wouldn't make sense. >>>>>>> >>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I >>>>>>> consider this application specific and so this would be included >>>>>>> in a feature tag registered in the global tree as stated in the >>>>>>> draft "RFC 6809 [1] provides that addresses of intermediaries can >>>>>>> be communicated as a value of an associated feature-capability >>>>>>> indicator so it would be appropriate to define feature capability >>>>>>> indicators as part of the global tree to communicate the GRUU of >>>>>>> the intermediary and hence this is outside the scope of this >>>>>>> document." - RFC 6809 states " If additional data about a >>>>>>> supported feature needs to be conveyed, such as the address of >>>>>>> the SIP entity that indicated support of the feature, then the >>>>>>> feature definition needs to define a way to convey that >>>>>>> information as a value of the associated feature-capability >>>>>>> indicator." However I think the SIP specific capability >>>>>>> indicators such as methods, extensions and events should >>>>>>> appropriately be registered in the SIP tree not as proprietary >>>>>>> indicator >>>>>> s in the global tree. >>>>>> >>>>>> So you have defined a sip tree feature tag that is only useful in >>>>>> conjunction with another feature tag from the global tree. >>>>>> And the description of this feature tag doesn't even mention that. >>>>>> >>>>>> And this all implies a completely non-standard call model - doing >>>>>> conferencing in a way inconsistent with RFC 4579. >>>>>> >>>>>> ISTM that if 4579 doesn't work for you then you should be back >>>>>> proposing extensions/revisions to it. >>>>>> >>>>>>> If there is a conference bridge in the signaling path, then I >>>>>>> would expect it to be the UAC. >>>>>>> >>>>>>> [AA] Although a "standard" way to invoke a conference is to send >>>>>>> a REFER to the other UAs to invite them to the conference focus, >>>>>>> in many deployments a scenario exists where a call involves an >>>>>>> IP-PBX or Telephony Application Server (TAS) that can act as a >>>>>>> focus for the conference. A participant of a call can then create >>>>>>> a conference by sending a REFER request in dialog to the IP-PBX >>>>>>> or TAS to use 3PCC to Invite other users to a conference. Reasons for this are 1. >>>>>>> Not all UAs support REFER, >>>>>> >>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), >>>>>> but it *could become* a focus. >>>>>> >>>>>> The concept that a dialog may contain intermediaries that can be >>>>>> addressed to do stuff is not part of any sip standard that I am >>>>>> aware of. I don't care too much as long as the "stuff" is >>>>>> application stuff that is outside the scope of sip. But when it is >>>>>> alternative ways to do stuff that sip supports, then I get upset. >>>>>> >>>>>>> 2. Many SBCs reject REFER requests going outside domains because >>>>>>> of the potential for charging fraud (referring to a premium rate >>>>>>> number >>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to join >>>>>>> the conference may be charged for initiating the call when the >>>>>>> scenario is that the initiator of the conference should be charged. >>>>>>> 4. No need to obtain and distribute conference URIs. >>>>>>> Problem is how to achieve the same behavior without dialog reuse >>>>>>> which has been deprecated by RFC 6665? >>>>>> >>>>>> Then maybe the problem needs to be brought up, and a standard >>>>>> solution proposed, rather than simply enabling a proprietary mechanism. >>>>>> >>>>>>> As another example, consider section 5.1: >>>>>>> >>>>>>> Descrition: >>>>>>> This Feature-capability indicator indicates that the intermediary >>>>>>> supports audio as a streaming media type. >>>>>>> ... >>>>>>> Examples of typical use: An IP PBX indicating that it is >>>>>>> capable of accepting and initiating sessions with audio as a >>>>>>> streaming media type. >>>>>>> >>>>>>> This definition *implies* an assumption about the working >>>>>>> environment >>>>>>> - one that AFAIK is new. It implies that you need to know that >>>>>>> intermediaries support a media type before you can use it. Would >>>>>>> it be bad if there were no intermediaries, and so none indicated this? >>>>>>> What if some intermediary *did* indicate support, but some other >>>>>>> doesn't, but doesn't indicate that it doesn't? >>>>>>> >>>>>>> Bottom line: how would the presence or absence of this feature >>>>>>> tag affect subsequent usage? >>>>>>> >>>>>>> [AA] The absence of the streaming types does not indicate that >>>>>>> the intermediary does not support the media type and SDP offer >>>>>>> answer will ultimately determine what can or cannot be used if >>>>>>> another session is initiated involving the intermediary. However >>>>>>> the presence of the media type in a Feature-caps header field >>>>>>> does explictly confirm that the intermediary does support the >>>>>>> media type and in the scenario where a UA has a choice of >>>>>>> multiple intermediaries it could use for a conference it might >>>>>>> choose to use the one that explicitly indicates it supports the media types the UA wants to use. >>>>>> >>>>>> So the UA will be able to discover that *some* intermediary >>>>>> supports media it is interested in. And it can tell that *some* >>>>>> intermediary says it is a focus. It doesn't know if they are the same intermediary. >>>>>> >>>>>> And then via some other feature tag it obtains the URI of *some* >>>>>> intermediary on the signaling path. Or maybe it gets more than one >>>>>> of these. >>>>>> >>>>>> It then makes a leap of faith and conflates all those things, to >>>>>> determine that the URI identifies a focus that supports this media type. >>>>>> >>>>>> Even then, exactly what does that mean? It may or may not mean >>>>>> that it supports mixing that media type in a conference. >>>>>> >>>>>>> As I stated already I don't care that much about these streaming >>>>>>> media types. >>>>>> >>>>>>> I could go on, but this is enough for now. >>>>>>> >>>>>>> [AA] My motivation for this is that currently 3GPP are updating >>>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>>> >>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with >>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather >>>>>>> than forwarding it all the way to the remote UA. >>>>>> >>>>>> And 6665 deprecates dial reuse in most of those cases. >>>>>> Without dialog reuse, the intermediaries don't get an opportunity >>>>>> to intercept those. >>>>>> >>>>>>> In order to know that an intermediary supports the target dialog >>>>>>> mechanism needed for a REFER request sent outside the dialog to >>>>>>> work we need sip.extensions as a feature-capability indicator. In >>>>>>> order to know that the needed event package is supported by the >>>>>>> intermediary so we can SUBSCROBE outside the dialog to an >>>>>>> intermediary we need sip.events as a feature-capability indicator. >>>>>> >>>>>> Then I think you should be back here with a problem statement and >>>>>> a request for how to get sip to solve it. >>>>>> >>>>>> And you should touch base with Christer on this. He may have a >>>>>> different opinion on the relevance of feature-caps as a solution. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>>> >>>>>>>> I have submitted a new draft to sipcore to register a number of >>>>>>>> feature capability indicators in the SIP tree (based upon some >>>>>>>> of the existing SIP media feature tags). The draft can be found at: >>>>>>>> >>>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00. >>>>>>>> txt >>>>>>>> >>>>>>>> Since there will not be a sipcore session at IETF#88 can we >>>>>>>> have an offline discussion on how to progress this draft (which >>>>>>>> hopefully is fairly straightforward as it just registers feature >>>>>>>> capabilities indicators with IANA). I wouldn't want to have to >>>>>>>> wait until March next year for a decision on progressing this. >>>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>>> ---------------------------------------------------------------- >>>>>>>> --- >>>>>>>> - >>>>>>>> - This transmission (including any attachments) may contain >>>>>>>> confidential information, privileged material (including >>>>>>>> material protected by the solicitor-client or other applicable >>>>>>>> privileges), or constitute non-public information. Any use of >>>>>>>> this information by anyone other than the intended recipient is >>>>>>>> prohibited. If you have received this transmission in error, >>>>>>>> please immediately reply to the sender and delete this >>>>>>>> information from your system. Use, dissemination, distribution, >>>>>>>> or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>>>>> >>>>>>> ----------------------------------------------------------------- >>>>>>> --- >>>>>>> - This transmission (including any attachments) may contain >>>>>>> confidential information, privileged material (including material >>>>>>> protected by the solicitor-client or other applicable >>>>>>> privileges), or constitute non-public information. Any use of >>>>>>> this information by anyone other than the intended recipient is >>>>>>> prohibited. If you have received this transmission in error, >>>>>>> please immediately reply to the sender and delete this >>>>>>> information from your system. Use, dissemination, distribution, >>>>>>> or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> -- This transmission (including any attachments) may contain >>>>> confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>>> >>>>> >>>> >>>> -------------------------------------------------------------------- >>>> - This transmission (including any attachments) may contain >>>> confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>> >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > > From christer.holmberg@ericsson.com Fri Oct 25 11:47:56 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3482911E81BE for ; Fri, 25 Oct 2013 11:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE7dXl3hP1ve for ; Fri, 25 Oct 2013 11:47:45 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AC48011E8176 for ; Fri, 25 Oct 2013 11:47:29 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-ad-526abcc0e594 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BB.C6.16099.0CCBA625; Fri, 25 Oct 2013 20:47:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Fri, 25 Oct 2013 20:47:27 +0200 From: Christer Holmberg To: Paul Kyzivat , Andrew Allen , SIPCORE Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0bGFP58SWd7NsEuoIpBbiHeDAZoFv+AsgAACDAU= Date: Fri, 25 Oct 2013 18:47:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F70BF@ESESSMB209.ericsson.se> References: <526A7ADF.8010106@alum.mit.edu> , <526ABAAC.1000304@alum.mit.edu> In-Reply-To: <526ABAAC.1000304@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4F70BFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+Jvje6BPVlBBpeO8Fvcn7eV0WLFhgOs Fl9/bGJzYPb4+/4Dk8eshrXsHkuW/GQKYI7isklJzcksSy3St0vgynj4+xJTwaVnLBVXvz5g aWDc2sHSxcjJISFgIvHyylt2CFtM4sK99WxdjFwcQgKHGSUmdN9hhnCWMEr0PTgPVMXBwSZg IdH9TxukQUQgR2LvxlNMILawQKLEqyszmCHiSRI3N9xjhLCtJG59ewK2jEVAVWLt5ldMIGN4 BXwlPl60gBh/klFi+bkHbCA1nAI6ElP7Z4LNYQQ66PupNWDzmQXEJW49mc8EcaiAxJI955kh bFGJl4//sULYShI/NlxigajPl9iy+CdYPa+AoMTJmU9YJjCKzEIyahaSsllIyiDiehI3pk5h g7C1JZYtfM0MYetKzPh3CKrGWuLbv7OsyGoWMHKsYmTPTczMSS833MQIjLWDW37r7mA8dU7k EKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhnNaQz3718Uo1Vf82tx9W8 UncXN/w+9U6pNp2p+QDf23DPyeZTVhXuC5lpE+0puPhrwLaNO/Sevj4SUfJaVoDnCuuPl9l2 fsUzZZzk31+1qe063N4wQWN29/184Tc7TltFTi7uOfvuefde/urzNZ7znu06WzTlhJZjzG7h LxvmBiUrbJ599uBZJZbijERDLeai4kQAO1ZuKYMCAAA= Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 18:47:56 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4F70BFESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >> The next revisions will contain more details on what each FCI (as Christ= er now calls them means). >> >> If some are not well understood I will remove them from the draft (i.e. = drop the rat holes) >> >> I think my email exchange with Christer clarifies the other points. >> >> Does this represent in principle a way forward? > > Maybe. We'll have to see how it goes. > > The challenge is, I think, that you want to bring in a bunch of the 3840 > feature tags, and have them mean something akin to what they do as > feature tags when used as FCIs. But there needs to be some way to > describe what *each* one means. It's not immediately clear to me how to > do that. As I said in another reply, I think that the FCIs that use the +sip.method = etc FCIs need to describe how they are used in conjunction. Example: Feature-Caps: *;+g.x;+sip.methods=3D"INVITE" Feature-Caps: *;+g.y;+sip.methods=3D"INVITE" The FCI specifications for +g.x and +g.y need to describe how they are used= together with +sip.methods, if there is a relationship. Otherwise +sip.methods only means that the entity that inserted the FCIs su= pport "INVITE". Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, October 25, 2013 10:06 AM > To: Andrew Allen; Gonzalo.Camarillo@ericsson.com > Cc: rlb@ipv.sx; adam@nostrum.com; christer.holmberg@ericsson.com; mary.ie= tf.barnes@gmail.com > Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-ca= p-indicators > > Andrew, > > (I see this is still on the private thread. I'll reply here, but this exc= hange should probably be reposted to the sipcore list as part of the public= discussion of the draft.) > > On 10/24/13 10:41 PM, Andrew Allen wrote: >> >> Paul >> >> I am happy to do a revision with more details on the semantics of the ca= pability indicators. However I don't think it should be held to a very much= higher bar than the details in RFC 3840 and the other media feature tag RF= Cs regarding the meaning of those tags. > > Keep in mind that the driving force for the definition of feature tags in= 3840 was in support of callerprefs (3841). So the context for the use of f= eature tags was that they would be placed on Contacts in REGISTER requests.= So you can interpret the definitions in that context: that a request sent = to an AOR using callerprefs can affect the choice of which device the reque= st goes to according to the capabilities it wants. In that context audio, v= ideo, isfocus all make sense. > > Their use on Contacts in dialogs was derivative to that: because callerpr= ef support is optional, there is no guarantee that the device you reach via= callerprefs will have the capabilities you requested. So the values in the= contact help confirm what you got. > > Of course they have since been used other ways. And the descriptions of t= hem don't necessarily reflect that. IMO that is a defect due to the evoluti= on of use. > > I'm looking for the same sort of context for use with the feature-caps. > > In private discussion you indicated to me that you expected the feature c= aps to be grouped - with one of them giving the URI of the device that the = other tags apply to. I guess this would end up looking something like: > > Feature-Caps: *;g.uri=3D"sip:foo@example.com";audio > Feature-Caps: *;g.uri=3D"sip:bar@example.com";audio;video;isfocus > Feature-Caps: *;g.uri=3D"sip:baz@example.com";text > > (I'm making up g.uri for the example.) > > And then presumably somebody on the signaling path will "shop" in the fea= ture caps for the capabilities it wants, and then send a request to that UR= I, with the expectation that the UA responding will have those capabilities= . > >> The semantics should be no different than those of the corresponding ex= isting media feature tag if it is present in the Contact header. > > Note that 6809 says: > > When a SIP entity receives a SIP request, or response, that contains > one or more Feature-Caps header fields, the feature-capability > indicators in the header field inform the entity about the features > and capabilities supported by entities in the SIP message signaling > path. The procedure by which features and capabilities are invoked > are outside the scope of this specification and MUST be described by > individual feature-capability indicator specifications. > > A Feature-Caps header field value cannot convey the address of the > SIP entity that inserted the Feature-Caps header field. If > additional data about a supported feature needs to be conveyed, such > as the address of the SIP entity that indicated support of the > feature, then the feature definition needs to define a way to convey > that information as a value of the associated feature-capability > indicator. > > This was discussed at length while that RFC was under consideration. Yet = the definitions of the tags in *this* draft don't specify that. > >> The registration templates currently reference the RFC 3840 and the othe= r RFCs that define the other media feature tags that correspond to these fe= ature capability indicators. > > And those definitions were written to be understood in the context of 384= 0/3841. They make sense in that context, but not in *this* context. > > Thanks, > Paul > >> But if more explicit detail is required then I can add some more text o= r alternatively remove the less important ones if they are going to become = rat holes. The ones I regard as really important and urgent are sip.methods= , sip.extensions and sip.events the meaning of which I think should be quit= e clear. >> >> Andrew >> >> ----- Original Message ----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com >> >> Cc: rlb@ipv.sx ; adam@nostrum.com ; >> christer.holmberg@ericsson.com ; >> mary.ietf.barnes@gmail.com ; Paul Kyzivat >> >> Subject: Re: New sipcore draft submission >> draft-allen-sipcore-sip-tree-cap-indicators >> >> On 10/24/13 4:07 PM, Andrew Allen wrote: >>> >>> Paul >>> >>> Ok >>> >>> So we are basically where I thought we were at when I submitted the dra= ft. >>> >>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who= indicates interest) can have some offline discussion in Vancouver on wheth= er and how to progress this. >> >> As I indicated again on the sipcore list, I found the that the draft >> didn't explain nearly enough to allow meaningful use of these. >> I know you replied, and I will continue the conversation there. >> But I will be opposed to these until and unless the draft (and notably >> the descriptions of the tags) are clear about how one could figure out >> what can do in the presence of the tags that one couldn't do without >> them. AND, that the behavior that suggests doesn't "break" sip. (E.g., >> by advocating a new and incompatible way to do something.) >> >> We can continue this on the sipcore list. >> >> Thanks, >> Paul >> >>> Andrew >>> >>> ----- Original Message ----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >>> To: Andrew Allen; Gonzalo Camarillo >>> Cc: Richard Barnes (rlb@ipv.sx) ; Adam Roach >>> (adam@nostrum.com) ; Christer Holmberg >>> (christer.holmberg@ericsson.com) ; >>> Mary Barnes (mary.ietf.barnes@gmail.com) >>> Subject: Re: New sipcore draft submission >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> On 10/24/13 2:17 PM, Andrew Allen wrote: >>>> Paul >>>> >>>> That is fine. Although Mary in her reply to me seemed to indicate mayb= e there was a possibility to use some of the DISPATCH spare time for a SIPC= ORE session for this. Is that a possibility? >>>> >>>> I already replied to your post >>> >>> I discussed that with Adam. We decided we can't set a precedent to >>> spin up a session to discuss a draft that hasn't had substantial >>> (any) list discussion. >>> >>> But list discussion is always welcome. >>> >>> Sorry, >>> Paul >>> >>>> Andrew >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, October 24, 2013 1:31 PM >>>> To: Andrew Allen; Gonzalo Camarillo >>>> Cc: Richard Barnes (rlb@ipv.sx); Adam Roach (adam@nostrum.com); >>>> Christer Holmberg (christer.holmberg@ericsson.com) >>>> Subject: Re: New sipcore draft submission >>>> draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> Andrew, >>>> >>>> I spoke with Mary about it, and we concluded that dispatch isn't right= for this. (In addition to being clearly sipcore, it didn't meet the deadli= ne for dispatch.) I was wrong to encourage you that way. >>>> >>>> So no official live discussion in Vancouver. (But informal >>>> discussion >>>> fine.) >>>> >>>> I'll resend my private comments to the sipcore list to kickstart some = discussion there. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>>> I just emailed Mary asking for agenda time. Should I cancel that requ= est? >>>>> >>>>> -----Original Message----- >>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>> Sent: Thursday, October 24, 2013 1:00 PM >>>>> To: Paul Kyzivat >>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx); Adam Roach >>>>> (adam@nostrum.com); Christer Holmberg >>>>> (christer.holmberg@ericsson.com) >>>>> Subject: Re: New sipcore draft submission >>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>> >>>>> Hi Paul, >>>>> >>>>> given that you think this belongs to SIPCORE, I do not see the need t= o run it through DISPATCH. Please, start technical discussions on the draft= on the SIPCORE list. >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>>> Paul >>>>>>> >>>>>>> Thanks for reviewing the draft already and giving me early feedback= . >>>>>>> >>>>>>> My responses below inline (prepended with [AA). >>>>>>> >>>>>>> Can I ask the ADs to determine ASAP if this needs to go to >>>>>>> DISPATCH first or not. As outlined below my view is that it is >>>>>>> unnecessary for every little thing to go to DISPATCH as this just >>>>>>> creates additional delay and overhead. If it is to be discussed >>>>>>> in DISPATCH then I definitely would want agenda time atIETF#88 for = this. >>>>>> >>>>>> Having now seen Andrew's responses to my initial questions, I >>>>>> think this >>>>>> *needs* to be carefully considered by sipcore. IMO this has the >>>>>> potential to create a dialect of sip that is incompatible with >>>>>> normal usage. (Maybe IMS has already done that. But this will make >>>>>> it >>>>>> worse.) >>>>>> >>>>>> But if there is a desire to discuss it publicly in Vancouver then >>>>>> dispatch is the opportunity and so some discussion on the dispatch >>>>>> list in advance of that would be appropriate. >>>>>> >>>>>> I'll defer to the ADs on this. >>>>>> >>>>>> More inline. >>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx); Gonzalo Camarillo >>>>>>> (Gonzalo.Camarillo@ericsson.com); Adam Roach (adam@nostrum.com) >>>>>>> Subject: Re: New sipcore draft submission >>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>> >>>>>>> Andrew, >>>>>>> >>>>>>> On a legalistic note, its questionable to me whether this kind of >>>>>>> action falls within the scope of sipcore. OTOH, among existing >>>>>>> wgs, sipcore is probably the best suited to discuss the proposal. >>>>>>> We could take it to DISPATCH. I think DISPATCH has extra time in >>>>>>> its agenda for Vancouver, so that might be one option for you. >>>>>>> But then I don't know where dispatch would dispatch it. It may be >>>>>>> that AD sponsored is the best way to go. >>>>>>> >>>>>>> [AA] It seemed to me that sipcore was the right place. This draft >>>>>>> registers feature-capability indicators in a registry that was >>>>>>> created by a sipcore RFC (RFC 6809). You could in my view make an >>>>>>> argument that this should even have been done as part of RFC 6809. >>>>>> >>>>>> If this was just a matter of registering some new feature caps >>>>>> that were not controversial, then I don't think sipcore needs to be = involved. >>>>>> >>>>>> But as I mentioned above, I do consider these controversial. >>>>>> >>>>>>> Discussing it now on the dispatch list would be a good start >>>>>>> toward discussing it at the dispatch session. >>>>>>> >>>>>>> [AA] Can I ask the ADs to determine if this needs to go to >>>>>>> DISPATCH first or not. My view is that it is unnecessary for >>>>>>> every little thing to go to DISPATCH as this just creates additiona= l delay and overhead. >>>>>>> This just registers some indicators in an existing IANA registry >>>>>>> and is not (or should not be IMHO) a major project. >>>>>> >>>>>> To me this is a matter of whether you want to be opportunistic. >>>>>> If this went to dispatch I would now recommend that it be >>>>>> dispatched to sipcore. So its a matter of whether you want to talk >>>>>> about it in the dispatch meeting. >>>>>> >>>>>>> Regarding substance, this draft troubles me. It takes >>>>>>> feature-caps in exactly the direction that I found most >>>>>>> concerning about the mechanism in the first place. >>>>>>> >>>>>>> Your draft partitions the existing media feature tags into two >>>>>>> sets >>>>>>> - those that would be useful as feature-capability-indicators, >>>>>>> and those that aren't. But I see no explanation of the criteria >>>>>>> used to make this distinction, nor can I think of one. >>>>>>> >>>>>>> [AA] I based this decision on the following criteria: If a >>>>>>> feature tag was potentially at all useful for an intermediary to >>>>>>> indicate it then include it in the registry. The ones not >>>>>>> included are either directly associated with the user >>>>>>> (intermediaries are not directly associated with the user) or >>>>>>> would only ever have one value (e.g automata). I am not sure >>>>>>> that every feature-capability indicator proposed to be registered >>>>>>> is actually useful but then I don't think every media feature tag >>>>>>> registered by RFC 3840 is either (I doubt very much if there are >>>>>>> implementation using the sip.application or sip.control feature >>>>>>> tags). I don't think RFC 3840 goes into a lot of details >>>>>>> justifying of ever registered media feature tag and specifying >>>>>>> the details of how they would be used either. I am willing to >>>>>>> remove any feature-capability indicators that are controversial exc= ept that I think we definitely need sip.extensions, sip.methods and sip.eve= nts. >>>>>>> There is a significant overhead to writing an >>>>>> d progressing internet drafts so my view is lets register all that >>>>>> might be remotely useful in the same document. >>>>>> >>>>>> The judgement of "useful" is reasonable. But I still can't discern >>>>>> what the use is from the iana registration descriptions. >>>>>> >>>>>>> For the ones that you have requested feature capability >>>>>>> indicators, I cannot figure out what using them would mean. For >>>>>>> example, when I see isFocus on a Contact header I know I am in a >>>>>>> conference, and that I can subscribe to the conference event >>>>>>> package at the contact URI. If I see isFocus in a Feature-Caps head= er, what does it mean? >>>>>>> What can I do once I know this? >>>>>>> >>>>>>> Section 5.14 of this draft says: >>>>>>> >>>>>>> This Feature-capability indicator indicates that the i= ntermediary >>>>>>> is a conference server, also known as a focus, and is = capable of >>>>>>> mixing together the media for all calls to the same UR= I. >>>>>>> ... >>>>>>> Examples of typical use: A conference bridge >>>>>>> indicating that it >>>>>>> is a conference bridge and is capable of acting as >>>>>>> a conference >>>>>>> focus for this session. >>>>>>> >>>>>>> [AA] the presence of isfocus in a Feature-Caps header field means >>>>>>> that a UA can initiate a conference by sending a REFER request to >>>>>>> the intermediary to invite another user and create a multi user >>>>>>> conference from the 1-1 session. >>>>>>> >>>>>>> Note that Feature-Caps doesn't indicate which entity has this >>>>>>> capability, only that something does. And since this would >>>>>>> presumably only be used if it wasn't the UAC of the request, >>>>>>> sending a subscribe to the contact address of the UAC wouldn't make= sense. >>>>>>> >>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I >>>>>>> consider this application specific and so this would be included >>>>>>> in a feature tag registered in the global tree as stated in the >>>>>>> draft "RFC 6809 [1] provides that addresses of intermediaries can >>>>>>> be communicated as a value of an associated feature-capability >>>>>>> indicator so it would be appropriate to define feature capability >>>>>>> indicators as part of the global tree to communicate the GRUU of >>>>>>> the intermediary and hence this is outside the scope of this >>>>>>> document." - RFC 6809 states " If additional data about a >>>>>>> supported feature needs to be conveyed, such as the address of >>>>>>> the SIP entity that indicated support of the feature, then the >>>>>>> feature definition needs to define a way to convey that >>>>>>> information as a value of the associated feature-capability >>>>>>> indicator." However I think the SIP specific capability >>>>>>> indicators such as methods, extensions and events should >>>>>>> appropriately be registered in the SIP tree not as proprietary >>>>>>> indicator >>>>>> s in the global tree. >>>>>> >>>>>> So you have defined a sip tree feature tag that is only useful in >>>>>> conjunction with another feature tag from the global tree. >>>>>> And the description of this feature tag doesn't even mention that. >>>>>> >>>>>> And this all implies a completely non-standard call model - doing >>>>>> conferencing in a way inconsistent with RFC 4579. >>>>>> >>>>>> ISTM that if 4579 doesn't work for you then you should be back >>>>>> proposing extensions/revisions to it. >>>>>> >>>>>>> If there is a conference bridge in the signaling path, then I >>>>>>> would expect it to be the UAC. >>>>>>> >>>>>>> [AA] Although a "standard" way to invoke a conference is to send >>>>>>> a REFER to the other UAs to invite them to the conference focus, >>>>>>> in many deployments a scenario exists where a call involves an >>>>>>> IP-PBX or Telephony Application Server (TAS) that can act as a >>>>>>> focus for the conference. A participant of a call can then create >>>>>>> a conference by sending a REFER request in dialog to the IP-PBX >>>>>>> or TAS to use 3PCC to Invite other users to a conference. Reasons f= or this are 1. >>>>>>> Not all UAs support REFER, >>>>>> >>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), >>>>>> but it *could become* a focus. >>>>>> >>>>>> The concept that a dialog may contain intermediaries that can be >>>>>> addressed to do stuff is not part of any sip standard that I am >>>>>> aware of. I don't care too much as long as the "stuff" is >>>>>> application stuff that is outside the scope of sip. But when it is >>>>>> alternative ways to do stuff that sip supports, then I get upset. >>>>>> >>>>>>> 2. Many SBCs reject REFER requests going outside domains because >>>>>>> of the potential for charging fraud (referring to a premium rate >>>>>>> number >>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to join >>>>>>> the conference may be charged for initiating the call when the >>>>>>> scenario is that the initiator of the conference should be charged. >>>>>>> 4. No need to obtain and distribute conference URIs. >>>>>>> Problem is how to achieve the same behavior without dialog reuse >>>>>>> which has been deprecated by RFC 6665? >>>>>> >>>>>> Then maybe the problem needs to be brought up, and a standard >>>>>> solution proposed, rather than simply enabling a proprietary mechani= sm. >>>>>> >>>>>>> As another example, consider section 5.1: >>>>>>> >>>>>>> Descrition: >>>>>>> This Feature-capability indicator indicates that the i= ntermediary >>>>>>> supports audio as a streaming media type. >>>>>>> ... >>>>>>> Examples of typical use: An IP PBX indicating that = it is >>>>>>> capable of accepting and initiating sessions with a= udio as a >>>>>>> streaming media type. >>>>>>> >>>>>>> This definition *implies* an assumption about the working >>>>>>> environment >>>>>>> - one that AFAIK is new. It implies that you need to know that >>>>>>> intermediaries support a media type before you can use it. Would >>>>>>> it be bad if there were no intermediaries, and so none indicated th= is? >>>>>>> What if some intermediary *did* indicate support, but some other >>>>>>> doesn't, but doesn't indicate that it doesn't? >>>>>>> >>>>>>> Bottom line: how would the presence or absence of this feature >>>>>>> tag affect subsequent usage? >>>>>>> >>>>>>> [AA] The absence of the streaming types does not indicate that >>>>>>> the intermediary does not support the media type and SDP offer >>>>>>> answer will ultimately determine what can or cannot be used if >>>>>>> another session is initiated involving the intermediary. However >>>>>>> the presence of the media type in a Feature-caps header field >>>>>>> does explictly confirm that the intermediary does support the >>>>>>> media type and in the scenario where a UA has a choice of >>>>>>> multiple intermediaries it could use for a conference it might >>>>>>> choose to use the one that explicitly indicates it supports the med= ia types the UA wants to use. >>>>>> >>>>>> So the UA will be able to discover that *some* intermediary >>>>>> supports media it is interested in. And it can tell that *some* >>>>>> intermediary says it is a focus. It doesn't know if they are the sam= e intermediary. >>>>>> >>>>>> And then via some other feature tag it obtains the URI of *some* >>>>>> intermediary on the signaling path. Or maybe it gets more than one >>>>>> of these. >>>>>> >>>>>> It then makes a leap of faith and conflates all those things, to >>>>>> determine that the URI identifies a focus that supports this media t= ype. >>>>>> >>>>>> Even then, exactly what does that mean? It may or may not mean >>>>>> that it supports mixing that media type in a conference. >>>>>> >>>>>>> As I stated already I don't care that much about these streaming >>>>>>> media types. >>>>>> >>>>>>> I could go on, but this is enough for now. >>>>>>> >>>>>>> [AA] My motivation for this is that currently 3GPP are updating >>>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>>> >>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with >>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather >>>>>>> than forwarding it all the way to the remote UA. >>>>>> >>>>>> And 6665 deprecates dial reuse in most of those cases. >>>>>> Without dialog reuse, the intermediaries don't get an opportunity >>>>>> to intercept those. >>>>>> >>>>>>> In order to know that an intermediary supports the target dialog >>>>>>> mechanism needed for a REFER request sent outside the dialog to >>>>>>> work we need sip.extensions as a feature-capability indicator. In >>>>>>> order to know that the needed event package is supported by the >>>>>>> intermediary so we can SUBSCROBE outside the dialog to an >>>>>>> intermediary we need sip.events as a feature-capability indicator. >>>>>> >>>>>> Then I think you should be back here with a problem statement and >>>>>> a request for how to get sip to solve it. >>>>>> >>>>>> And you should touch base with Christer on this. He may have a >>>>>> different opinion on the relevance of feature-caps as a solution. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>>> >>>>>>>> I have submitted a new draft to sipcore to register a number of >>>>>>>> feature capability indicators in the SIP tree (based upon some >>>>>>>> of the existing SIP media feature tags). The draft can be found at= : >>>>>>>> >>>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators= -00. >>>>>>>> txt >>>>>>>> >>>>>>>> Since there will not be a sipcore session at IETF#88 can we >>>>>>>> have an offline discussion on how to progress this draft (which >>>>>>>> hopefully is fairly straightforward as it just registers feature >>>>>>>> capabilities indicators with IANA). I wouldn't want to have to >>>>>>>> wait until March next year for a decision on progressing this. >>>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>>> ---------------------------------------------------------------- >>>>>>>> --- >>>>>>>> - >>>>>>>> - This transmission (including any attachments) may contain >>>>>>>> confidential information, privileged material (including >>>>>>>> material protected by the solicitor-client or other applicable >>>>>>>> privileges), or constitute non-public information. Any use of >>>>>>>> this information by anyone other than the intended recipient is >>>>>>>> prohibited. If you have received this transmission in error, >>>>>>>> please immediately reply to the sender and delete this >>>>>>>> information from your system. Use, dissemination, distribution, >>>>>>>> or reproduction of this transmission by unintended recipients is n= ot authorized and may be unlawful. >>>>>>> >>>>>>> ----------------------------------------------------------------- >>>>>>> --- >>>>>>> - This transmission (including any attachments) may contain >>>>>>> confidential information, privileged material (including material >>>>>>> protected by the solicitor-client or other applicable >>>>>>> privileges), or constitute non-public information. Any use of >>>>>>> this information by anyone other than the intended recipient is >>>>>>> prohibited. If you have received this transmission in error, >>>>>>> please immediately reply to the sender and delete this >>>>>>> information from your system. Use, dissemination, distribution, >>>>>>> or reproduction of this transmission by unintended recipients is no= t authorized and may be unlawful. >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> -- This transmission (including any attachments) may contain >>>>> confidential information, privileged material (including material pro= tected by the solicitor-client or other applicable privileges), or constitu= te non-public information. Any use of this information by anyone other than= the intended recipient is prohibited. If you have received this transmissi= on in error, please immediately reply to the sender and delete this informa= tion from your system. Use, dissemination, distribution, or reproduction of= this transmission by unintended recipients is not authorized and may be un= lawful. >>>>> >>>>> >>>> >>>> -------------------------------------------------------------------- >>>> - This transmission (including any attachments) may contain >>>> confidential information, privileged material (including material prot= ected by the solicitor-client or other applicable privileges), or constitut= e non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this transmissio= n in error, please immediately reply to the sender and delete this informat= ion from your system. Use, dissemination, distribution, or reproduction of = this transmission by unintended recipients is not authorized and may be unl= awful. >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the solic= itor-client or other applicable privileges), or constitute non-public infor= mation. Any use of this information by anyone other than the intended recip= ient is prohibited. If you have received this transmission in error, please= immediately reply to the sender and delete this information from your syst= em. Use, dissemination, distribution, or reproduction of this transmission = by unintended recipients is not authorized and may be unlawful. >>> >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential i= nformation, privileged material (including material protected by the solici= tor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recipi= ent is prohibited. If you have received this transmission in error, please = immediately reply to the sender and delete this information from your syste= m. Use, dissemination, distribution, or reproduction of this transmission b= y unintended recipients is not authorized and may be unlawful. >> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B1C4F70BFESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

 

>> The next revi= sions will contain more details on what each FCI (as Christer now calls the= m means).
>>
>> If some are not well understood I will remove them from the draft = (i.e. drop  the rat holes)
>>
>> I think my email exchange with Christer clarifies the other points= .
>>
>> Does this represent in principle a way forward?
>
> Maybe. We'll have to see how it goes.
>
> The challenge is, I think, that you want to bring in a bunch of the 38= 40
> feature tags, and have them mean something akin to what they do as > feature tags when used as FCIs. But there needs to be some way to
> describe what *each* one means. It's not immediately clear to me how t= o
> do that.

As I said in another r= eply, I think that the FCIs that use the +sip.method etc FCIs need to d= escribe how they are used in conjunction.

 

Example:=

 

Feature-Caps: *;+g= .x;+sip.methods=3D"INVITE"

Feature-Caps: *;+g= .y;+sip.methods=3D"INVITE"

 

The FCI specifications= for +g.x and +g.y need to describe how they are used tog= ether with +sip.methods, if there is a relationship.

 

Otherwise +sip.met= hods only means that the entity that inserted the FCIs support "INVITE= ".

 

Regards,=

 

Christer=

 

 

 

 

 

> -----Original Mes= sage-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: Friday, October 25, 2013 10:06 AM
> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com
> Cc: rlb@ipv.sx; adam@nostrum.com; christer.holmberg@ericsson.com; mary= .ietf.barnes@gmail.com
> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree= -cap-indicators
>
> Andrew,
>
> (I see this is still on the private thread. I'll reply here, but this = exchange should probably be reposted to the sipcore list as part of the pub= lic discussion of the draft.)
>
> On 10/24/13 10:41 PM, Andrew Allen wrote:
>>
>> Paul
>>
>> I am happy to do a revision with more details on the semantics of = the capability indicators. However I don't think it should be held to a ver= y much higher bar than the details in RFC 3840 and the other media feature = tag RFCs regarding the meaning of those tags.
>
> Keep in mind that the driving force for the definition of feature tags= in 3840 was in support of callerprefs (3841). So the context for the use o= f feature tags was that they would be placed on Contacts in REGISTER reques= ts. So you can interpret the definitions in that context: that a request sent to an AOR using callerprefs can affec= t the choice of which device the request goes to according to the capabilit= ies it wants. In that context audio, video, isfocus all make sense.
>
> Their use on Contacts in dialogs was derivative to that: because calle= rpref support is optional, there is no guarantee that the device you reach = via callerprefs will have the capabilities you requested. So the values in = the contact help confirm what you got.
>
> Of course they have since been used other ways. And the descriptions o= f them don't necessarily reflect that. IMO that is a defect due to the evol= ution of use.
>
> I'm looking for the same sort of context for use with the feature-caps= .
>
> In private discussion you indicated to me that you expected the featur= e caps to be grouped - with one of them giving the URI of the device that t= he other tags apply to. I guess this would end up looking something like: >
>     Feature-Caps: *;g.uri=3D"sip:foo@example.= com";audio
>     Feature-Caps: *;g.uri=3D"sip:bar@example.= com";audio;video;isfocus
>     Feature-Caps: *;g.uri=3D"sip:baz@example.= com";text
>
> (I'm making up g.uri for the example.)
>
> And then presumably somebody on the signaling path will "shop&quo= t; in the feature caps for the capabilities it wants, and then send a reque= st to that URI, with the expectation that the UA responding will have those= capabilities.
>
>> The semantics should be no different than those of  the corre= sponding existing media  feature tag if it is present in the Contact h= eader.
>
> Note that 6809 says:
>
>      When a SIP entity receives a SIP request= , or response, that contains
>      one or more Feature-Caps header fields, = the feature-capability
>      indicators in the header field inform th= e entity about the features
>      and capabilities supported by entities i= n the SIP message signaling
>      path.  The procedure by which featu= res and capabilities are invoked
>      are outside the scope of this specificat= ion and MUST be described by
>      individual feature-capability indicator = specifications.
>
>      A Feature-Caps header field value cannot= convey the address of the
>      SIP entity that inserted the Feature-Cap= s header field.  If
>      additional data about a supported featur= e needs to be conveyed, such
>      as the address of the SIP entity that in= dicated support of the
>      feature, then the feature definition nee= ds to define a way to convey
>      that information as a value of the assoc= iated feature-capability
>      indicator.
>
> This was discussed at length while that RFC was under consideration. Y= et the definitions of the tags in *this* draft don't specify that.
>
>> The registration templates currently reference the RFC 3840 and th= e other RFCs that define the other media feature tags that correspond to th= ese feature capability indicators.
>
> And those definitions were written to be understood in the context of = 3840/3841. They make sense in that context, but not in *this* context.
>
>        Thanks,
>        Paul
>
>> But if more explicit detail is required then I can add some more t= ext  or alternatively remove the less important ones if they are going= to become rat holes. The ones I regard as really important and urgent are = sip.methods, sip.extensions and sip.events the meaning of which I think should be quite clear.
>>
>> Andrew
>>
>> ----- Original Message -----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com
>> <Gonzalo.Camarillo@ericsson.com>
>> Cc: rlb@ipv.sx <rlb@ipv.sx>; adam@nostrum.com <adam@nostr= um.com>;
>> christer.holmberg@ericsson.com <christer.holmberg@ericsson.com&= gt;;
>> mary.ietf.barnes@gmail.com <mary.ietf.barnes@gmail.com>; Pau= l Kyzivat
>> <pkyzivat@alum.mit.edu>
>> Subject: Re: New sipcore draft submission
>> draft-allen-sipcore-sip-tree-cap-indicators
>>
>> On 10/24/13 4:07 PM, Andrew Allen wrote:
>>>
>>> Paul
>>>
>>> Ok
>>>
>>> So we are basically where I thought we were at when I submitte= d the draft.
>>>
>>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone= else who indicates interest) can have some offline discussion in Vancouver= on whether and how to progress this.
>>
>> As I indicated again on the sipcore list, I found the that the dra= ft
>> didn't explain nearly enough to allow meaningful use of these.
>> I know you replied, and I will continue the conversation there. >> But I will be opposed to these until and unless the draft (and not= ably
>> the descriptions of the tags) are clear about how one could figure= out
>> what can do in the presence of the tags that one couldn't do witho= ut
>> them. AND, that the behavior that suggests doesn't "break&quo= t; sip. (E.g.,
>> by advocating a new and incompatible way to do something.)
>>
>> We can continue this on the sipcore list.
>>
>>       Thanks,
>>       Paul
>>
>>> Andrew
>>>
>>> ----- Original Message -----
>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Tim= e
>>> To: Andrew Allen; Gonzalo Camarillo <Gonzalo.Camarillo@eric= sson.com>
>>> Cc: Richard Barnes (rlb@ipv.sx) <rlb@ipv.sx>; Adam Roach=
>>> (adam@nostrum.com) <adam@nostrum.com>; Christer Holmberg=
>>> (christer.holmberg@ericsson.com) <christer.holmberg@ericsso= n.com>;
>>> Mary Barnes (mary.ietf.barnes@gmail.com) <mary.ietf.barnes@= gmail.com>
>>> Subject: Re: New sipcore draft submission
>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>
>>> On 10/24/13 2:17 PM, Andrew Allen wrote:
>>>> Paul
>>>>
>>>> That is fine. Although Mary in her reply to me seemed to i= ndicate maybe there was a possibility to use some of the DISPATCH spare tim= e for a SIPCORE session for this. Is that a possibility?
>>>>
>>>> I already replied to your post
>>>
>>> I discussed that with Adam. We decided we can't set a preceden= t to
>>> spin up a session to discuss a draft that hasn't had substanti= al
>>> (any) list discussion.
>>>
>>> But list discussion is always welcome.
>>>
>>>      Sorry,
>>>      Paul
>>>
>>>> Andrew
>>>>
>>>> -----Original Message-----
>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>> Sent: Thursday, October 24, 2013 1:31 PM
>>>> To: Andrew Allen; Gonzalo Camarillo
>>>> Cc: Richard Barnes (rlb@ipv.sx); Adam Roach (adam@nostrum.= com);
>>>> Christer Holmberg (christer.holmberg@ericsson.com)
>>>> Subject: Re: New sipcore draft submission
>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>
>>>> Andrew,
>>>>
>>>> I spoke with Mary about it, and we concluded that dispatch= isn't right for this. (In addition to being clearly sipcore, it didn't mee= t the deadline for dispatch.) I was wrong to encourage you that way.
>>>>
>>>> So no official live discussion in Vancouver. (But informal=
>>>> discussion
>>>> fine.)
>>>>
>>>> I'll resend my private comments to the sipcore list to kic= kstart some discussion there.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>> On 10/24/13 1:01 PM, Andrew Allen wrote:
>>>>> I just emailed Mary asking for agenda time. Should I c= ancel that request?
>>>>>
>>>>> -----Original Message-----
>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.co= m]
>>>>> Sent: Thursday, October 24, 2013 1:00 PM
>>>>> To: Paul Kyzivat
>>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx); Adam Ro= ach
>>>>> (adam@nostrum.com); Christer Holmberg
>>>>> (christer.holmberg@ericsson.com)
>>>>> Subject: Re: New sipcore draft submission
>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>
>>>>> Hi Paul,
>>>>>
>>>>> given that you think this belongs to SIPCORE, I do not= see the need to run it through DISPATCH. Please, start technical discussio= ns on the draft on the SIPCORE list.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Gonzalo
>>>>>
>>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote:
>>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote:
>>>>>>> Paul
>>>>>>>
>>>>>>> Thanks for reviewing the draft already and giv= ing me early feedback.
>>>>>>>
>>>>>>> My responses below inline (prepended with [AA)= .
>>>>>>>
>>>>>>> Can I ask the ADs to determine ASAP if this ne= eds to go to
>>>>>>> DISPATCH first or not. As outlined below my vi= ew is that it is
>>>>>>> unnecessary for every little thing to go to DI= SPATCH as this just
>>>>>>> creates additional delay and overhead. If it i= s to be discussed
>>>>>>> in DISPATCH then I definitely would want agend= a time atIETF#88 for this.
>>>>>>
>>>>>> Having now seen Andrew's responses to my initial q= uestions, I
>>>>>> think this
>>>>>> *needs* to be carefully considered by sipcore. IMO= this has the
>>>>>> potential to create a dialect of sip that is incom= patible with
>>>>>> normal usage. (Maybe IMS has already done that. Bu= t this will make
>>>>>> it
>>>>>> worse.)
>>>>>>
>>>>>> But if there is a desire to discuss it publicly in= Vancouver then
>>>>>> dispatch is the opportunity and so some discussion= on the dispatch
>>>>>> list in advance of that would be appropriate.
>>>>>>
>>>>>> I'll defer to the ADs on this.
>>>>>>
>>>>>> More inline.
>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM
>>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx);= Gonzalo Camarillo
>>>>>>> (Gonzalo.Camarillo@ericsson.com); Adam Roach (= adam@nostrum.com)
>>>>>>> Subject: Re: New sipcore draft submission
>>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>>
>>>>>>> Andrew,
>>>>>>>
>>>>>>> On a legalistic note, its questionable to me w= hether this kind of
>>>>>>> action falls within the scope of sipcore. OTOH= , among existing
>>>>>>> wgs, sipcore is probably the best suited to di= scuss the proposal.
>>>>>>> We could take it to DISPATCH. I think DISPATCH= has extra time in
>>>>>>> its agenda for Vancouver, so that might be one= option for you.
>>>>>>> But then I don't know where dispatch would dis= patch it. It may be
>>>>>>> that AD sponsored is the best way to go.
>>>>>>>
>>>>>>> [AA] It seemed to me that sipcore was the righ= t place. This draft
>>>>>>> registers feature-capability indicators in a r= egistry that was
>>>>>>> created by a sipcore RFC (RFC 6809). You could= in my view make an
>>>>>>> argument that this should even have been done = as part of RFC 6809.
>>>>>>
>>>>>> If this was just a matter of registering some new = feature caps
>>>>>> that were not controversial, then I don't think si= pcore needs to be involved.
>>>>>>
>>>>>> But as I mentioned above, I do consider these cont= roversial.
>>>>>>
>>>>>>> Discussing it now on the dispatch list would b= e a good start
>>>>>>> toward discussing it at the dispatch session.<= br> >>>>>>>
>>>>>>> [AA] Can I ask the ADs to determine if this ne= eds to go to
>>>>>>> DISPATCH first or not. My view is that it is u= nnecessary for
>>>>>>> every little thing to go to DISPATCH as this j= ust creates additional delay and overhead.
>>>>>>> This just registers some indicators in an exis= ting IANA registry
>>>>>>> and is not (or should not be IMHO) a major pro= ject.
>>>>>>
>>>>>> To me this is a matter of whether you want to be o= pportunistic.
>>>>>> If this went to dispatch I would now recommend tha= t it be
>>>>>> dispatched to sipcore. So its a matter of whether = you want to talk
>>>>>> about it in the dispatch meeting.
>>>>>>
>>>>>>> Regarding substance, this draft troubles me. I= t takes
>>>>>>> feature-caps in exactly the direction that I f= ound most
>>>>>>> concerning about the mechanism in the first pl= ace.
>>>>>>>
>>>>>>> Your draft partitions the existing media featu= re tags into two
>>>>>>> sets
>>>>>>> - those that would be useful as feature-capabi= lity-indicators,
>>>>>>> and those that aren't. But I see no explanatio= n of the criteria
>>>>>>> used to make this distinction, nor can I think= of one.
>>>>>>>
>>>>>>> [AA] I based this decision on the following cr= iteria: If a
>>>>>>> feature tag was potentially at all useful for = an intermediary to
>>>>>>> indicate it then include it in the registry. T= he ones not
>>>>>>> included are either directly associated with t= he user
>>>>>>> (intermediaries are not  directly associa= ted with the user) or
>>>>>>> would only ever have one value (e.g automata).=   I am not sure
>>>>>>> that every feature-capability indicator propos= ed to be registered
>>>>>>> is actually useful but then I don't think ever= y media feature tag
>>>>>>> registered by RFC 3840 is either (I doubt very= much if there are
>>>>>>> implementation using the sip.application or si= p.control feature
>>>>>>> tags). I don't think RFC 3840 goes into a lot = of details
>>>>>>> justifying of ever registered media feature ta= g and specifying
>>>>>>> the details of how they would be used either.&= nbsp; I am willing to
>>>>>>> remove any feature-capability indicators that = are controversial except that I think we definitely need sip.extensions, si= p.methods and sip.events.
>>>>>>> There is a significant overhead to writing an<= br> >>>>>> d progressing internet drafts so my view is lets r= egister all that
>>>>>> might be remotely useful in the same document.
>>>>>>
>>>>>> The judgement of "useful" is reasonable.= But I still can't discern
>>>>>> what the use is from the iana registration descrip= tions.
>>>>>>
>>>>>>> For the ones that you have requested feature c= apability
>>>>>>> indicators, I cannot figure out what using the= m would mean. For
>>>>>>> example, when I see isFocus on a Contact heade= r I know I am in a
>>>>>>> conference, and that I can subscribe to the co= nference event
>>>>>>> package at the contact URI. If I see isFocus i= n a Feature-Caps header, what does it mean?
>>>>>>> What can I do once I know this?
>>>>>>>
>>>>>>> Section 5.14 of this draft says:
>>>>>>>
>>>>>>>        = ;      This Feature-capability indicator indicates= that the intermediary
>>>>>>>        = ;      is a conference server, also known as a foc= us, and is capable of
>>>>>>>        = ;      mixing together the media for all calls to = the same URI.
>>>>>>> ...
>>>>>>>        = ;         Examples of typical use: = A conference bridge
>>>>>>> indicating that it
>>>>>>>        = ;         is a conference bridge an= d is capable of acting as
>>>>>>> a conference
>>>>>>>        = ;         focus for this session. >>>>>>>
>>>>>>> [AA] the presence of isfocus in a Feature-Caps= header field means
>>>>>>> that a UA can initiate a conference by sending= a REFER request to
>>>>>>> the intermediary to invite another user and cr= eate a multi user
>>>>>>> conference from the 1-1 session.
>>>>>>>
>>>>>>> Note that Feature-Caps doesn't indicate which = entity has this
>>>>>>> capability, only that something does. And sinc= e this would
>>>>>>> presumably only be used if it wasn't the UAC o= f the request,
>>>>>>> sending a subscribe to the contact address of = the UAC wouldn't make sense.
>>>>>>>
>>>>>>> [AA] Yes the GRUU of the intermediary would be= needed but I
>>>>>>> consider this application specific and so this= would be included
>>>>>>> in a feature tag registered in the global tree= as stated in the
>>>>>>> draft "RFC 6809 [1] provides that address= es of intermediaries can
>>>>>>> be communicated as a value of an associated fe= ature-capability
>>>>>>> indicator so it would be appropriate to define= feature capability
>>>>>>> indicators as part of the global tree to commu= nicate the GRUU of
>>>>>>> the intermediary and hence this is outside the= scope of this
>>>>>>> document."  - RFC 6809 states "= If additional data about a
>>>>>>> supported feature needs to be conveyed, such a= s the address of
>>>>>>> the SIP entity that indicated support of the f= eature, then the
>>>>>>> feature definition needs to define a way to co= nvey that
>>>>>>> information as a value of the associated featu= re-capability
>>>>>>> indicator." However I think the SIP speci= fic capability
>>>>>>> indicators such as methods, extensions and eve= nts should
>>>>>>> appropriately be registered in the SIP tree no= t as proprietary
>>>>>>> indicator
>>>>>> s in the global tree.
>>>>>>
>>>>>> So you have defined a sip tree feature tag that is= only useful in
>>>>>> conjunction with another feature tag from the glob= al tree.
>>>>>> And the description of this feature tag doesn't ev= en mention that.
>>>>>>
>>>>>> And this all implies a completely non-standard cal= l model - doing
>>>>>> conferencing in a way inconsistent with RFC 4579.<= br> >>>>>>
>>>>>> ISTM that if 4579 doesn't work for you then you sh= ould be back
>>>>>> proposing extensions/revisions to it.
>>>>>>
>>>>>>> If there is a conference bridge in the signali= ng path, then I
>>>>>>> would expect it to be the UAC.
>>>>>>>
>>>>>>> [AA] Although a "standard" way to in= voke a conference is to send
>>>>>>> a REFER to the other UAs to invite them to the= conference focus,
>>>>>>> in many deployments a scenario exists where a = call involves an
>>>>>>> IP-PBX or Telephony Application Server (TAS) t= hat can act as a
>>>>>>> focus for the conference. A participant of a c= all can then create
>>>>>>> a conference by sending a REFER request in dia= log to the IP-PBX
>>>>>>> or TAS to use 3PCC to Invite other users to a = conference. Reasons for this are 1.
>>>>>>> Not all UAs support REFER,
>>>>>>
>>>>>> So you are saying the intermediary isn't a focus (= its a B2BUA),
>>>>>> but it *could become* a focus.
>>>>>>
>>>>>> The concept that a dialog may contain intermediari= es that can be
>>>>>> addressed to do stuff is not part of any sip stand= ard that I am
>>>>>> aware of. I don't care too much as long as the &qu= ot;stuff" is
>>>>>> application stuff that is outside the scope of sip= . But when it is
>>>>>> alternative ways to do stuff that sip supports, th= en I get upset.
>>>>>>
>>>>>>> 2. Many SBCs reject REFER requests going outsi= de domains because
>>>>>>> of the potential for charging fraud (referring= to a premium rate
>>>>>>> number
>>>>>>> etc) 3. A User receiving a REFER and then usin= g an INVITE to join
>>>>>>> the conference may be charged for initiating&n= bsp; the call when the
>>>>>>> scenario is that the initiator of the conferen= ce should be charged.
>>>>>>> 4. No need to obtain and distribute conference= URIs.
>>>>>>> Problem is how to achieve the same behavior wi= thout dialog reuse
>>>>>>> which has been deprecated by RFC 6665?
>>>>>>
>>>>>> Then maybe the problem needs to be brought up, and= a standard
>>>>>> solution proposed, rather than simply enabling a p= roprietary mechanism.
>>>>>>
>>>>>>> As another example, consider section 5.1:
>>>>>>>
>>>>>>>        = ;      Descrition:
>>>>>>>        = ;      This Feature-capability indicator indicates= that the intermediary
>>>>>>>        = ;      supports audio as a streaming media type. >>>>>>> ...
>>>>>>>        = ;         Examples of typical use: = An IP PBX indicating that it is
>>>>>>>        = ;         capable of accepting and = initiating sessions with audio as a
>>>>>>>        = ;         streaming media type.
>>>>>>>
>>>>>>> This definition *implies* an assumption about = the working
>>>>>>> environment
>>>>>>> - one that AFAIK is new. It implies that you n= eed to know that
>>>>>>> intermediaries support a media type before you= can use it. Would
>>>>>>> it be bad if there were no intermediaries, and= so none indicated this?
>>>>>>> What if some intermediary *did* indicate suppo= rt, but some other
>>>>>>> doesn't, but doesn't indicate that it doesn't?=
>>>>>>>
>>>>>>> Bottom line: how would the presence or absence= of this feature
>>>>>>> tag affect subsequent usage?
>>>>>>>
>>>>>>> [AA] The absence of the streaming types does n= ot indicate that
>>>>>>> the intermediary does not support the media ty= pe and SDP offer
>>>>>>> answer will ultimately determine what can or c= annot be used if
>>>>>>> another session is initiated involving the int= ermediary. However
>>>>>>> the presence of the media type in a Feature-ca= ps header field
>>>>>>> does explictly confirm that the intermediary d= oes support the
>>>>>>> media type and in the scenario where a UA has = a choice of
>>>>>>> multiple intermediaries it could use for a con= ference it might
>>>>>>> choose to use the one that explicitly indicate= s it supports the media types the UA wants to use.
>>>>>>
>>>>>> So the UA will be able to discover that *some* int= ermediary
>>>>>> supports media it is interested in. And it can tel= l that *some*
>>>>>> intermediary says it is a focus. It doesn't know i= f they are the same intermediary.
>>>>>>
>>>>>> And then via some other feature tag it obtains the= URI of *some*
>>>>>> intermediary on the signaling path. Or maybe it ge= ts more than one
>>>>>> of these.
>>>>>>
>>>>>> It then makes a leap of faith and conflates all th= ose things, to
>>>>>> determine that the URI identifies a focus that sup= ports this media type.
>>>>>>
>>>>>> Even then, exactly what does that mean? It may or = may not mean
>>>>>> that it supports mixing that media type in a confe= rence.
>>>>>>
>>>>>>> As I stated already I don't care that much abo= ut these streaming
>>>>>>> media types.
>>>>>>
>>>>>>> I could go on, but this is enough for now.
>>>>>>>
>>>>>>> [AA] My motivation for this is that currently = 3GPP are updating
>>>>>>> their specifications to use RFC 6665 instead o= f RFC 3265.
>>>>>>
>>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE = and REFER with
>>>>>>> intermediaries accepting the REFER or SUBSCRIB= E request rather
>>>>>>> than forwarding it all the way to the remote U= A.
>>>>>>
>>>>>> And 6665 deprecates dial reuse in most of those ca= ses.
>>>>>> Without dialog reuse, the intermediaries don't get= an opportunity
>>>>>> to intercept those.
>>>>>>
>>>>>>> In order to know that an intermediary supports= the target dialog
>>>>>>> mechanism  needed for a REFER request sen= t outside the dialog to
>>>>>>> work we need sip.extensions as a feature-capab= ility indicator. In
>>>>>>> order to know that the needed event package is= supported by the
>>>>>>> intermediary so we can SUBSCROBE outside the d= ialog to an
>>>>>>> intermediary we need sip.events as a feature-c= apability indicator.
>>>>>>
>>>>>> Then I think you should be back here with a proble= m statement and
>>>>>> a request for how to get sip to solve it.
>>>>>>
>>>>>> And you should touch base with Christer on this. H= e may have a
>>>>>> different opinion on the relevance of feature-caps= as a solution.
>>>>>>
>>>>>>        &nb= sp; Thanks,
>>>>>>        &nb= sp; Paul
>>>>>>
>>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote:
>>>>>>>> Adam, Paul, Richard, Gonzalo
>>>>>>>>
>>>>>>>> I have submitted a new draft to sipcore&nb= sp; to register a number of
>>>>>>>> feature capability indicators in the SIP t= ree (based upon some
>>>>>>>> of the existing SIP media feature tags). T= he draft can be found at:
>>>>>>>>
>>>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00.<= br> >>>>>>>> txt
>>>>>>>>
>>>>>>>> Since there will not be a sipcore session = at IETF#88  can we
>>>>>>>> have an offline discussion on how to progr= ess this draft (which
>>>>>>>> hopefully is fairly straightforward as it = just registers feature
>>>>>>>> capabilities indicators with IANA). I woul= dn't want to have to
>>>>>>>> wait until March next year for a decision = on progressing this.
>>>>>>>>
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>> ------------------------------------------= ----------------------
>>>>>>>> ---
>>>>>>>> -
>>>>>>>> - This transmission (including any attachm= ents) may contain
>>>>>>>> confidential information, privileged mater= ial (including
>>>>>>>> material protected by the solicitor-client= or other applicable
>>>>>>>> privileges), or constitute non-public info= rmation. Any use of
>>>>>>>> this information by anyone other than the = intended recipient is
>>>>>>>> prohibited. If you have received this tran= smission in error,
>>>>>>>> please immediately reply to the sender and= delete this
>>>>>>>> information from your system. Use, dissemi= nation, distribution,
>>>>>>>> or reproduction of this transmission by un= intended recipients is not authorized and may be unlawful.
>>>>>>>
>>>>>>> ----------------------------------------------= -------------------
>>>>>>> ---
>>>>>>> - This transmission (including any attachments= ) may contain
>>>>>>> confidential information, privileged material = (including material
>>>>>>> protected by the solicitor-client or other app= licable
>>>>>>> privileges), or constitute non-public informat= ion. Any use of
>>>>>>> this information by anyone other than the inte= nded recipient is
>>>>>>> prohibited. If you have received this transmis= sion in error,
>>>>>>> please immediately reply to the sender and del= ete this
>>>>>>> information from your system. Use, disseminati= on, distribution,
>>>>>>> or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------= -------------
>>>>> -- This transmission (including any attachments) may c= ontain
>>>>> confidential information, privileged material (includi= ng material protected by the solicitor-client or other applicable privilege= s), or constitute non-public information. Any use of this information by an= yone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, disseminat= ion, distribution, or reproduction of this transmission by unintended recip= ients is not authorized and may be unlawful.
>>>>>
>>>>>
>>>>
>>>> ----------------------------------------------------------= ----------
>>>> - This transmission (including any attachments) may contai= n
>>>> confidential information, privileged material (including m= aterial protected by the solicitor-client or other applicable privileges), = or constitute non-public information. Any use of this information by anyone= other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, disseminat= ion, distribution, or reproduction of this transmission by unintended recip= ients is not authorized and may be unlawful.
>>>>
>>>>
>>>
>>> --------------------------------------------------------------= -------
>>> This transmission (including any attachments) may contain conf= idential information, privileged material (including material protected by = the solicitor-client or other applicable privileges), or constitute non-pub= lic information. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>
>>>
>>
>> ------------------------------------------------------------------= ---
>> This transmission (including any attachments) may contain confiden= tial information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute non-public = information. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>
>>
>
> ---------------------------------------------------------------------<= br> > This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the soli= citor-client or other applicable privileges), or constitute non-public info= rmation. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>
>

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--_000_7594FB04B1934943A5C02806D1A2204B1C4F70BFESESSMB209erics_-- From pkyzivat@alum.mit.edu Fri Oct 25 11:49:55 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B42511E81AB for ; Fri, 25 Oct 2013 11:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.615 X-Spam-Level: X-Spam-Status: No, score=0.615 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4SL1ss9Eg6g for ; Fri, 25 Oct 2013 11:49:50 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3A111E8176 for ; Fri, 25 Oct 2013 11:49:48 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta13.westchester.pa.mail.comcast.net with comcast id hV981m0050EZKEL5DWpnUG; Fri, 25 Oct 2013 18:49:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id hWpn1m0063ZTu2S3MWpnjo; Fri, 25 Oct 2013 18:49:47 +0000 Message-ID: <526ABD4B.1030404@alum.mit.edu> Date: Fri, 25 Oct 2013 14:49:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382726987; bh=68eRUzMMgQilz0eZEOyO63PW9gT0OxwgYcuNJ+wmpkc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bQCP9iI4Tq55kVc+MYB79BQFIJSlUqPXg9gLmxhK2iU+jsZxJXJsNk/gxJ1zEsBae DuqEqH70etGiRJWQCp3XBsNntBaISej1uWg+Wj6mkkJbDM2ckbOM/E4U67QJ5gn/TX oB9D1BudDzbztd3BVoDRIG+dmZnWAi7BylMK5CHv/Vzm9pIlN0T01guvv9IWgp0dDi NioDDc0dCAq0NHChTtkYlQzY3kMPvMwZigyfxcS+fSnu5R9rmy5qT17Xor15MggHV1 qAlkJtl6vKU5kkRsmzUJGcj0UiBzq9IXpagNW8dzuFRPdFIQoWZdDT0m6pLFvzpsUc f+2c4pz6QOxcA== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 18:49:55 -0000 On 10/25/13 2:03 PM, Christer Holmberg wrote: > (Moving to the SIPCORE list) > > Hi, > > > > Also all the FCIs in the same Featire-Caps header field apply to the > same entity. > > > > E.g. that for > > > > Feature-Caps: *, +FCI1; +FCI2, *; +FCI3; +FCI4 > > > > FCI1 and FCI2 apply to one logical entity > > and FCI3 and FCI4 apply to a different logical entity > > Correct. > > But, in general, keep in mind that a FCI value with an address > does NOT automatically indicates the address of the entity supporting > the feature - unless you explicitly say so in the FCI definition. It > only provides an address associated with a feature, and you need to > define the semantics of it in the FCI defintion. > > /Example:/ > > I support the find-Paul feature, and I insert a FCI: > > Feature-Caps: *, +g.find-paul="sip:pkyzivat@alum.mit.edu" > > Now, in this case the address does NOT point to my entity, but to Paul's > entity. My entity supports a feature, which provides Paul's address. > > So, if the FCI says: > > Feature-Caps: *, > +g.find-paul="sip:pkyzivat@alum.mit.edu";+sip.methods="invite" > > ...it doesn't automatically mean that I can contact Paul using INVITE. > By default it means that MY entity supports the INVITE method - which > from the find-paul feature perspective is useless information. > > So, in the FCI specification for +g.find-paul, I would have to > explictily describe how the FCI works in conjunction with other FCIs. I > would have to explicitly say that, when used together +sip.methods, the > +sip.methods indicates which SIP methods I can use to contact Paul > (using the address provide in the +g.find-paul FCI). So far I agree. But suppose there is also a find-christer FCI. So we have: Feature-Caps: * ;+g.find-paul="sip:pkyzivat@alum.mit.edu" ;+g.find-paul="sip:christer.holmberg@ericsson.com" ;+sip.methods="invite" And both find-paul and find-christer want to define the use of other FCIs. Then things start to become ambiguous. Should the description of find-paul specify what other FCIs "pertain" to it? Or should the description of sip.methods specify what FCI(s) provide the address at which it applies? Or both? What if paul and christer support different methods? Thanks, Paul > Section 5.3.8 in RFC 6809 also says: > > "If there is additional information about the feature-capability > indicator, it is recommended to describe such information. It can > include, for example, *names of related feature-capability > indicators*." > > So, in your case, I think the +g.3gpp.see_trans FCI specifiction would > have to specify how the FCI is used in conjuntion with other FCIs, > including the +sip.method FCI. > > Something like: "When the session transfer request is sent to the > address indicated by the FCI value, the +sip.method FCI indicates which > SIP methods can be used." > > Regards, > > Christer > > > > *From*: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > *Sent*: Friday, October 25, 2013 12:01 PM Central Standard Time > *To*: Andrew Allen; Paul Kyzivat ; Gonzalo > Camarillo > *Cc*: rlb@ipv.sx ; adam@nostrum.com ; > mary.ietf.barnes@gmail.com > *Subject*: RE: New sipcore draft submission > draft-allen-sipcore-sip-tree-cap-indicators > > Hi, > >>I think we can have an FCI > >> > >>Feature-Caps: *;+g.3ggp.sess_trans=”sip:foo@example.com;gr” > >> > >>Indicating that the entity supports 3GPP session transfer and the address where you send the session transfer request is sip:foo@example.com;gr > > Correct. The FCI itself indicates support of session transfer feature, > and the FCI value indicates the address associatd with the feature. > >>Also if I have: > >> > >>Feature-Caps: *;+g.3ggp.sess_trans=sip:foo@example.com;gr; +sip.extensions=”replaces, tdialog”; > +sip.methods=”invite, refer, bye, options, update, prack” > >> > >> This means the entity supports 3GPP session transfer and the address where you send the session transfer request is sip:foo@example.com;gr ... > > Correct. > >> ...supports the replaces and target dialog extensions and supports the following methods - invite, refer, bye, options, update, prack. > > Technically, what it means is that there is *AN* entity which supports > the features listed above, and the address is where you are to send the > session transfer request in order to trigger the 3GPP session transfer > feature. > > Regards, > > Christer > > *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] > *Sent:* Friday, October 25, 2013 10:25 AM > *To:* Paul Kyzivat; Andrew Allen; Gonzalo Camarillo > *Cc:* rlb@ipv.sx; adam@nostrum.com; mary.ietf.barnes@gmail.com > *Subject:* RE: New sipcore draft submission > draft-allen-sipcore-sip-tree-cap-indicators > > Hi, > > As Paul said, if one needs to provide address information associated > with a FCI, the address information cannot be a FCI of its own. It needs > to be a value of the FCI for which it is associated. > > Something like: > > Feature-Caps: *;+audio="sip:foo@example.com" > > (Also note that the "+" sign is mandatory for all FCIs - no matter which > registry tree they belong to) > > Regards, > > Christer > > ------------------------------------------------------------------------ > > *From:*Paul Kyzivat [pkyzivat@alum.mit.edu] > *Sent:* Friday, 25 October 2013 5:06 PM > *To:* Andrew Allen; Gonzalo Camarillo > *Cc:* rlb@ipv.sx ; adam@nostrum.com > ; Christer Holmberg; mary.ietf.barnes@gmail.com > > *Subject:* Re: New sipcore draft submission > draft-allen-sipcore-sip-tree-cap-indicators > > Andrew, > > (I see this is still on the private thread. I'll reply here, but this > exchange should probably be reposted to the sipcore list as part of the > public discussion of the draft.) > > On 10/24/13 10:41 PM, Andrew Allen wrote: >> >> Paul >> >> I am happy to do a revision with more details on the semantics of the capability indicators. However I don't think it should be held to a very much higher bar than the details in RFC 3840 and the other media feature tag RFCs regarding the meaning of those tags. > > Keep in mind that the driving force for the definition of feature tags > in 3840 was in support of callerprefs (3841). So the context for the use > of feature tags was that they would be placed on Contacts in REGISTER > requests. So you can interpret the definitions in that context: that a > request sent to an AOR using callerprefs can affect the choice of which > device the request goes to according to the capabilities it wants. In > that context audio, video, isfocus all make sense. > > Their use on Contacts in dialogs was derivative to that: because > callerpref support is optional, there is no guarantee that the device > you reach via callerprefs will have the capabilities you requested. So > the values in the contact help confirm what you got. > > Of course they have since been used other ways. And the descriptions of > them don't necessarily reflect that. IMO that is a defect due to the > evolution of use. > > I'm looking for the same sort of context for use with the feature-caps. > > In private discussion you indicated to me that you expected the feature > caps to be grouped - with one of them giving the URI of the device that > the other tags apply to. I guess this would end up looking something like: > > Feature-Caps: *;g.uri="sip:foo@example.com";audio > Feature-Caps: *;g.uri="sip:bar@example.com";audio;video;isfocus > Feature-Caps: *;g.uri="sip:baz@example.com";text > > (I'm making up g.uri for the example.) > > And then presumably somebody on the signaling path will "shop" in the > feature caps for the capabilities it wants, and then send a request to > that URI, with the expectation that the UA responding will have those > capabilities. > >> The semantics should be no different than those of the corresponding existing media feature tag if it is present in the Contact header. > > Note that 6809 says: > > When a SIP entity receives a SIP request, or response, that contains > one or more Feature-Caps header fields, the feature-capability > indicators in the header field inform the entity about the features > and capabilities supported by entities in the SIP message signaling > path. The procedure by which features and capabilities are invoked > are outside the scope of this specification and MUST be described by > individual feature-capability indicator specifications. > > A Feature-Caps header field value cannot convey the address of the > SIP entity that inserted the Feature-Caps header field. If > additional data about a supported feature needs to be conveyed, such > as the address of the SIP entity that indicated support of the > feature, then the feature definition needs to define a way to convey > that information as a value of the associated feature-capability > indicator. > > This was discussed at length while that RFC was under consideration. Yet > the definitions of the tags in *this* draft don't specify that. > >> The registration templates currently reference the RFC 3840 and the other RFCs that define the other media feature tags that correspond to these feature capability indicators. > > And those definitions were written to be understood in the context of > 3840/3841. They make sense in that context, but not in *this* context. > > Thanks, > Paul > >> But if more explicit detail is required then I can add some more text or alternatively remove the less important ones if they are going to become rat holes. The ones I regard as really important and urgent are sip.methods, sip.extensions and sip.events the meaning of which I think should be quite clear. >> >> Andrew >> >> ----- Original Message ----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >> To: Andrew Allen;Gonzalo.Camarillo@ericsson.com > > >> Cc:rlb@ipv.sx >; > adam@nostrum.com >; christer.holmberg@ericsson.com > >; mary.ietf.barnes@gmail.com > >; Paul Kyzivat > > >> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators >> >> On 10/24/13 4:07 PM, Andrew Allen wrote: >>> >>> Paul >>> >>> Ok >>> >>> So we are basically where I thought we were at when I submitted the draft. >>> >>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who indicates interest) can have some offline discussion in Vancouver on whether and how to progress this. >> >> As I indicated again on the sipcore list, I found the that the draft >> didn't explain nearly enough to allow meaningful use of these. >> I know you replied, and I will continue the conversation there. >> But I will be opposed to these until and unless the draft (and notably >> the descriptions of the tags) are clear about how one could figure out >> what can do in the presence of the tags that one couldn't do without >> them. AND, that the behavior that suggests doesn't "break" sip. (E.g., >> by advocating a new and incompatible way to do something.) >> >> We can continue this on the sipcore list. >> >> Thanks, >> Paul >> >>> Andrew >>> >>> ----- Original Message ----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >>> To: Andrew Allen; Gonzalo Camarillo > >>> Cc: Richard Barnes (rlb@ipv.sx ) >; Adam > Roach (adam@nostrum.com ) >; Christer Holmberg > (christer.holmberg@ericsson.com ) > >; Mary Barnes > (mary.ietf.barnes@gmail.com ) < > mary.ietf.barnes@gmail.com > >>> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators >>> >>> On 10/24/13 2:17 PM, Andrew Allen wrote: >>>> Paul >>>> >>>> That is fine. Although Mary in her reply to me seemed to indicate maybe there was a possibility to use some of the DISPATCH spare time for a SIPCORE session for this. Is that a possibility? >>>> >>>> I already replied to your post >>> >>> I discussed that with Adam. We decided we can't set a precedent to spin >>> up a session to discuss a draft that hasn't had substantial (any) list >>> discussion. >>> >>> But list discussion is always welcome. >>> >>> Sorry, >>> Paul >>> >>>> Andrew >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, October 24, 2013 1:31 PM >>>> To: Andrew Allen; Gonzalo Camarillo >>>> Cc: Richard Barnes (rlb@ipv.sx ); Adam Roach (adam@nostrum.com > ); Christer Holmberg > (christer.holmberg@ericsson.com ) >>>> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> Andrew, >>>> >>>> I spoke with Mary about it, and we concluded that dispatch isn't right for this. (In addition to being clearly sipcore, it didn't meet the deadline for dispatch.) I was wrong to encourage you that way. >>>> >>>> So no official live discussion in Vancouver. (But informal discussion >>>> fine.) >>>> >>>> I'll resend my private comments to the sipcore list to kickstart some discussion there. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>>> I just emailed Mary asking for agenda time. Should I cancel that request? >>>>> >>>>> -----Original Message----- >>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>> Sent: Thursday, October 24, 2013 1:00 PM >>>>> To: Paul Kyzivat >>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx ); Adam Roach >>>>> (adam@nostrum.com ); Christer Holmberg > (christer.holmberg@ericsson.com ) >>>>> Subject: Re: New sipcore draft submission >>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>> >>>>> Hi Paul, >>>>> >>>>> given that you think this belongs to SIPCORE, I do not see the need to run it through DISPATCH. Please, start technical discussions on the draft on the SIPCORE list. >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>>> Paul >>>>>>> >>>>>>> Thanks for reviewing the draft already and giving me early feedback. >>>>>>> >>>>>>> My responses below inline (prepended with [AA). >>>>>>> >>>>>>> Can I ask the ADs to determine ASAP if this needs to go to DISPATCH >>>>>>> first or not. As outlined below my view is that it is unnecessary >>>>>>> for every little thing to go to DISPATCH as this just creates >>>>>>> additional delay and overhead. If it is to be discussed in DISPATCH >>>>>>> then I definitely would want agenda time atIETF#88 for this. >>>>>> >>>>>> Having now seen Andrew's responses to my initial questions, I think >>>>>> this >>>>>> *needs* to be carefully considered by sipcore. IMO this has the >>>>>> potential to create a dialect of sip that is incompatible with normal >>>>>> usage. (Maybe IMS has already done that. But this will make it >>>>>> worse.) >>>>>> >>>>>> But if there is a desire to discuss it publicly in Vancouver then >>>>>> dispatch is the opportunity and so some discussion on the dispatch >>>>>> list in advance of that would be appropriate. >>>>>> >>>>>> I'll defer to the ADs on this. >>>>>> >>>>>> More inline. >>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx ); Gonzalo Camarillo >>>>>>> (Gonzalo.Camarillo@ericsson.com ); > Adam Roach (adam@nostrum.com ) >>>>>>> Subject: Re: New sipcore draft submission >>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>> >>>>>>> Andrew, >>>>>>> >>>>>>> On a legalistic note, its questionable to me whether this kind of >>>>>>> action falls within the scope of sipcore. OTOH, among existing wgs, >>>>>>> sipcore is probably the best suited to discuss the proposal. We >>>>>>> could take it to DISPATCH. I think DISPATCH has extra time in its >>>>>>> agenda for Vancouver, so that might be one option for you. But then >>>>>>> I don't know where dispatch would dispatch it. It may be that AD >>>>>>> sponsored is the best way to go. >>>>>>> >>>>>>> [AA] It seemed to me that sipcore was the right place. This draft >>>>>>> registers feature-capability indicators in a registry that was >>>>>>> created by a sipcore RFC (RFC 6809). You could in my view make an >>>>>>> argument that this should even have been done as part of RFC 6809. >>>>>> >>>>>> If this was just a matter of registering some new feature caps that >>>>>> were not controversial, then I don't think sipcore needs to be involved. >>>>>> >>>>>> But as I mentioned above, I do consider these controversial. >>>>>> >>>>>>> Discussing it now on the dispatch list would be a good start toward >>>>>>> discussing it at the dispatch session. >>>>>>> >>>>>>> [AA] Can I ask the ADs to determine if this needs to go to DISPATCH >>>>>>> first or not. My view is that it is unnecessary for every little >>>>>>> thing to go to DISPATCH as this just creates additional delay and overhead. >>>>>>> This just registers some indicators in an existing IANA registry and >>>>>>> is not (or should not be IMHO) a major project. >>>>>> >>>>>> To me this is a matter of whether you want to be opportunistic. >>>>>> If this went to dispatch I would now recommend that it be dispatched >>>>>> to sipcore. So its a matter of whether you want to talk about it in >>>>>> the dispatch meeting. >>>>>> >>>>>>> Regarding substance, this draft troubles me. It takes feature-caps >>>>>>> in exactly the direction that I found most concerning about the >>>>>>> mechanism in the first place. >>>>>>> >>>>>>> Your draft partitions the existing media feature tags into two sets >>>>>>> - those that would be useful as feature-capability-indicators, and >>>>>>> those that aren't. But I see no explanation of the criteria used to >>>>>>> make this distinction, nor can I think of one. >>>>>>> >>>>>>> [AA] I based this decision on the following criteria: If a feature >>>>>>> tag was potentially at all useful for an intermediary to indicate it >>>>>>> then include it in the registry. The ones not included are either >>>>>>> directly associated with the user (intermediaries are not directly >>>>>>> associated with the user) or would only ever have one value (e.g >>>>>>> automata). I am not sure that every feature-capability indicator >>>>>>> proposed to be registered is actually useful but then I don't think >>>>>>> every media feature tag registered by RFC 3840 is either (I doubt >>>>>>> very much if there are implementation using the sip.application or >>>>>>> sip.control feature tags). I don't think RFC 3840 goes into a lot of >>>>>>> details justifying of ever registered media feature tag and >>>>>>> specifying the details of how they would be used either. I am >>>>>>> willing to remove any feature-capability indicators that are >>>>>>> controversial except that I think we definitely need sip.extensions, sip.methods and sip.events. >>>>>>> There is a significant overhead to writing an >>>>>> d progressing internet drafts so my view is lets register all that >>>>>> might be remotely useful in the same document. >>>>>> >>>>>> The judgement of "useful" is reasonable. But I still can't discern >>>>>> what the use is from the iana registration descriptions. >>>>>> >>>>>>> For the ones that you have requested feature capability indicators, >>>>>>> I cannot figure out what using them would mean. For example, when I >>>>>>> see isFocus on a Contact header I know I am in a conference, and >>>>>>> that I can subscribe to the conference event package at the contact >>>>>>> URI. If I see isFocus in a Feature-Caps header, what does it mean? >>>>>>> What can I do once I know this? >>>>>>> >>>>>>> Section 5.14 of this draft says: >>>>>>> >>>>>>> This Feature-capability indicator indicates that the intermediary >>>>>>> is a conference server, also known as a focus, and is capable of >>>>>>> mixing together the media for all calls to the same URI. >>>>>>> ... >>>>>>> Examples of typical use: A conference bridge indicating >>>>>>> that it >>>>>>> is a conference bridge and is capable of acting as a >>>>>>> conference >>>>>>> focus for this session. >>>>>>> >>>>>>> [AA] the presence of isfocus in a Feature-Caps header field means >>>>>>> that a UA can initiate a conference by sending a REFER request to >>>>>>> the intermediary to invite another user and create a multi user >>>>>>> conference from the 1-1 session. >>>>>>> >>>>>>> Note that Feature-Caps doesn't indicate which entity has this >>>>>>> capability, only that something does. And since this would >>>>>>> presumably only be used if it wasn't the UAC of the request, sending >>>>>>> a subscribe to the contact address of the UAC wouldn't make sense. >>>>>>> >>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I consider >>>>>>> this application specific and so this would be included in a feature >>>>>>> tag registered in the global tree as stated in the draft "RFC 6809 >>>>>>> [1] provides that addresses of intermediaries can be communicated as >>>>>>> a value of an associated feature-capability indicator so it would be >>>>>>> appropriate to define feature capability indicators as part of the >>>>>>> global tree to communicate the GRUU of the intermediary and hence >>>>>>> this is outside the scope of this document." - RFC 6809 states " If >>>>>>> additional data about a supported feature needs to be conveyed, such >>>>>>> as the address of the SIP entity that indicated support of the >>>>>>> feature, then the feature definition needs to define a way to convey >>>>>>> that information as a value of the associated feature-capability >>>>>>> indicator." However I think the SIP specific capability indicators >>>>>>> such as methods, extensions and events should appropriately be >>>>>>> registered in the SIP tree not as proprietary indicator >>>>>> s in the global tree. >>>>>> >>>>>> So you have defined a sip tree feature tag that is only useful in >>>>>> conjunction with another feature tag from the global tree. >>>>>> And the description of this feature tag doesn't even mention that. >>>>>> >>>>>> And this all implies a completely non-standard call model - doing >>>>>> conferencing in a way inconsistent with RFC 4579. >>>>>> >>>>>> ISTM that if 4579 doesn't work for you then you should be back >>>>>> proposing extensions/revisions to it. >>>>>> >>>>>>> If there is a conference bridge in the signaling path, then I would >>>>>>> expect it to be the UAC. >>>>>>> >>>>>>> [AA] Although a "standard" way to invoke a conference is to send a >>>>>>> REFER to the other UAs to invite them to the conference focus, in >>>>>>> many deployments a scenario exists where a call involves an IP-PBX >>>>>>> or Telephony Application Server (TAS) that can act as a focus for >>>>>>> the conference. A participant of a call can then create a conference >>>>>>> by sending a REFER request in dialog to the IP-PBX or TAS to use >>>>>>> 3PCC to Invite other users to a conference. Reasons for this are 1. >>>>>>> Not all UAs support REFER, >>>>>> >>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), but >>>>>> it *could become* a focus. >>>>>> >>>>>> The concept that a dialog may contain intermediaries that can be >>>>>> addressed to do stuff is not part of any sip standard that I am aware >>>>>> of. I don't care too much as long as the "stuff" is application stuff >>>>>> that is outside the scope of sip. But when it is alternative ways to >>>>>> do stuff that sip supports, then I get upset. >>>>>> >>>>>>> 2. Many SBCs reject REFER requests going outside domains because of >>>>>>> the potential for charging fraud (referring to a premium rate number >>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to join >>>>>>> the conference may be charged for initiating the call when the >>>>>>> scenario is that the initiator of the conference should be charged. >>>>>>> 4. No need to obtain and distribute conference URIs. >>>>>>> Problem is how to achieve the same behavior without dialog reuse >>>>>>> which has been deprecated by RFC 6665? >>>>>> >>>>>> Then maybe the problem needs to be brought up, and a standard >>>>>> solution proposed, rather than simply enabling a proprietary mechanism. >>>>>> >>>>>>> As another example, consider section 5.1: >>>>>>> >>>>>>> Descrition: >>>>>>> This Feature-capability indicator indicates that the intermediary >>>>>>> supports audio as a streaming media type. >>>>>>> ... >>>>>>> Examples of typical use: An IP PBX indicating that it is >>>>>>> capable of accepting and initiating sessions with audio as a >>>>>>> streaming media type. >>>>>>> >>>>>>> This definition *implies* an assumption about the working >>>>>>> environment >>>>>>> - one that AFAIK is new. It implies that you need to know that >>>>>>> intermediaries support a media type before you can use it. Would it >>>>>>> be bad if there were no intermediaries, and so none indicated this? >>>>>>> What if some intermediary *did* indicate support, but some other >>>>>>> doesn't, but doesn't indicate that it doesn't? >>>>>>> >>>>>>> Bottom line: how would the presence or absence of this feature tag >>>>>>> affect subsequent usage? >>>>>>> >>>>>>> [AA] The absence of the streaming types does not indicate that the >>>>>>> intermediary does not support the media type and SDP offer answer >>>>>>> will ultimately determine what can or cannot be used if another >>>>>>> session is initiated involving the intermediary. However the >>>>>>> presence of the media type in a Feature-caps header field does >>>>>>> explictly confirm that the intermediary does support the media type >>>>>>> and in the scenario where a UA has a choice of multiple >>>>>>> intermediaries it could use for a conference it might choose to use >>>>>>> the one that explicitly indicates it supports the media types the UA wants to use. >>>>>> >>>>>> So the UA will be able to discover that *some* intermediary supports >>>>>> media it is interested in. And it can tell that *some* intermediary >>>>>> says it is a focus. It doesn't know if they are the same intermediary. >>>>>> >>>>>> And then via some other feature tag it obtains the URI of *some* >>>>>> intermediary on the signaling path. Or maybe it gets more than one of >>>>>> these. >>>>>> >>>>>> It then makes a leap of faith and conflates all those things, to >>>>>> determine that the URI identifies a focus that supports this media type. >>>>>> >>>>>> Even then, exactly what does that mean? It may or may not mean that >>>>>> it supports mixing that media type in a conference. >>>>>> >>>>>>> As I stated already I don't care that much about these streaming >>>>>>> media types. >>>>>> >>>>>>> I could go on, but this is enough for now. >>>>>>> >>>>>>> [AA] My motivation for this is that currently 3GPP are updating >>>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>>> >>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with >>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather than >>>>>>> forwarding it all the way to the remote UA. >>>>>> >>>>>> And 6665 deprecates dial reuse in most of those cases. >>>>>> Without dialog reuse, the intermediaries don't get an opportunity to >>>>>> intercept those. >>>>>> >>>>>>> In order to know that an intermediary supports the target dialog >>>>>>> mechanism needed for a REFER request sent outside the dialog to >>>>>>> work we need sip.extensions as a feature-capability indicator. In >>>>>>> order to know that the needed event package is supported by the >>>>>>> intermediary so we can SUBSCROBE outside the dialog to an >>>>>>> intermediary we need sip.events as a feature-capability indicator. >>>>>> >>>>>> Then I think you should be back here with a problem statement and a >>>>>> request for how to get sip to solve it. >>>>>> >>>>>> And you should touch base with Christer on this. He may have a >>>>>> different opinion on the relevance of feature-caps as a solution. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>>> >>>>>>>> I have submitted a new draft to sipcore to register a number of >>>>>>>> feature capability indicators in the SIP tree (based upon some of >>>>>>>> the existing SIP media feature tags). The draft can be found at: >>>>>>>> >>>>>>>>http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00. >>>>>>>> txt >>>>>>>> >>>>>>>> Since there will not be a sipcore session at IETF#88 can we have >>>>>>>> an offline discussion on how to progress this draft (which >>>>>>>> hopefully is fairly straightforward as it just registers feature >>>>>>>> capabilities indicators with IANA). I wouldn't want to have to wait >>>>>>>> until March next year for a decision on progressing this. >>>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>>> ------------------------------------------------------------------- >>>>>>>> - >>>>>>>> - This transmission (including any attachments) may contain >>>>>>>> confidential information, privileged material (including material >>>>>>>> protected by the solicitor-client or other applicable privileges), >>>>>>>> or constitute non-public information. Any use of this information >>>>>>>> by anyone other than the intended recipient is prohibited. If you >>>>>>>> have received this transmission in error, please immediately reply >>>>>>>> to the sender and delete this information from your system. Use, >>>>>>>> dissemination, distribution, or reproduction of this transmission >>>>>>>> by unintended recipients is not authorized and may be unlawful. >>>>>>> >>>>>>> -------------------------------------------------------------------- >>>>>>> - This transmission (including any attachments) may contain >>>>>>> confidential information, privileged material (including material >>>>>>> protected by the solicitor-client or other applicable privileges), >>>>>>> or constitute non-public information. Any use of this information by >>>>>>> anyone other than the intended recipient is prohibited. If you have >>>>>>> received this transmission in error, please immediately reply to the >>>>>>> sender and delete this information from your system. Use, >>>>>>> dissemination, distribution, or reproduction of this transmission by >>>>>>> unintended recipients is not authorized and may be unlawful. >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >>> >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and delete > this information from your system. Use, dissemination, distribution, or > reproduction of this transmission by unintended recipients is not > authorized and may be unlawful. > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and delete > this information from your system. Use, dissemination, distribution, or > reproduction of this transmission by unintended recipients is not > authorized and may be unlawful. > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Fri Oct 25 11:50:11 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F0211E813A for ; Fri, 25 Oct 2013 11:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M1I9yG2335M for ; Fri, 25 Oct 2013 11:49:59 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 73CA111E81B2 for ; Fri, 25 Oct 2013 11:49:57 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-9b-526abd545a79 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 09.E6.16099.45DBA625; Fri, 25 Oct 2013 20:49:56 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Fri, 25 Oct 2013 20:49:55 +0200 From: Christer Holmberg To: Paul Kyzivat , Andrew Allen , SIPCORE Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0bK7sjM7YJso6k2kkTJc/k8cqZoFwhgIgAAAgmI= Date: Fri, 25 Oct 2013 18:49:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F70E4@ESESSMB209.ericsson.se> References: <526A7ADF.8010106@alum.mit.edu> , <526ABAAC.1000304@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C4F70BF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4F70BF@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4F70E4ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+JvjW7I3qwgg4VrBC3uz9vKaLFiwwFW i68/NrE5MHv8ff+ByWNWw1p2jyVLfjIFMEdx2aSk5mSWpRbp2yVwZZzYMY+54NkHlorel4fZ GxinT2TpYuTkkBAwkZjw5x4ThC0mceHeejYQW0jgMKNE0yJfCHsJo8TRp95djBwcbAIWEt3/ tEHCIgI5Ens3ngJrFRZIlLjV/IodIp4kcfT0TEYI20pi0sWHrCA2i4CqxIymxWBreQV8JR63 7QSq4QIa38ckcXPXbLBBnAJ+Ev1rLoIVMQLd8/3UGrA4s4C4xK0n86HuFJBYsuc8M4QtKvHy 8T9WCFtJ4seGSywQ9fkSP+/uZIdYJihxcuYTlgmMIrOQjJqFpGwWkjKIuJ7EjalT2CBsbYll C18zQ9i6EjP+HYKqsZa4NbuLGVnNAkaOVYzsuYmZOenlhpsYgZF2cMtv3R2Mp86JHGKU5mBR Euf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjZYv113lb/+92WL6tac0691MHOjPu RLz8u+C807tJM6w/iLyzXC0T/MH80DWxrZ/r2+fM6dp00EnPr9396/Wk7DMRpT6BMQUv17n9 Lrz3atn0koTE4EcfUr4dO+kTrrJ74rmGjybV+7+s6HVn8Vo9xcQn+e6RiHcryr1FYi/+erDW 9Q8vkwJbuBJLcUaioRZzUXEiAEsGOn6CAgAA Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 18:50:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4F70E4ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As a side note, you can also indicate a SIP method as a URI parameter: sip:transfer@example.com;method=3Drefer ________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] on behalf of Chri= ster Holmberg [christer.holmberg@ericsson.com] Sent: Friday, 25 October 2013 9:47 PM To: Paul Kyzivat; Andrew Allen; SIPCORE Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators Hi, >> The next revisions will contain more details on what each FCI (as Christ= er now calls them means). >> >> If some are not well understood I will remove them from the draft (i.e. = drop the rat holes) >> >> I think my email exchange with Christer clarifies the other points. >> >> Does this represent in principle a way forward? > > Maybe. We'll have to see how it goes. > > The challenge is, I think, that you want to bring in a bunch of the 3840 > feature tags, and have them mean something akin to what they do as > feature tags when used as FCIs. But there needs to be some way to > describe what *each* one means. It's not immediately clear to me how to > do that. As I said in another reply, I think that the FCIs that use the +sip.method = etc FCIs need to describe how they are used in conjunction. Example: Feature-Caps: *;+g.x;+sip.methods=3D"INVITE" Feature-Caps: *;+g.y;+sip.methods=3D"INVITE" The FCI specifications for +g.x and +g.y need to describe how they are used= together with +sip.methods, if there is a relationship. Otherwise +sip.methods only means that the entity that inserted the FCIs su= pport "INVITE". Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, October 25, 2013 10:06 AM > To: Andrew Allen; Gonzalo.Camarillo@ericsson.com > Cc: rlb@ipv.sx; adam@nostrum.com; christer.holmberg@ericsson.com; mary.ie= tf.barnes@gmail.com > Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-ca= p-indicators > > Andrew, > > (I see this is still on the private thread. I'll reply here, but this exc= hange should probably be reposted to the sipcore list as part of the public= discussion of the draft.) > > On 10/24/13 10:41 PM, Andrew Allen wrote: >> >> Paul >> >> I am happy to do a revision with more details on the semantics of the ca= pability indicators. However I don't think it should be held to a very much= higher bar than the details in RFC 3840 and the other media feature tag RF= Cs regarding the meaning of those tags. > > Keep in mind that the driving force for the definition of feature tags in= 3840 was in support of callerprefs (3841). So the context for the use of f= eature tags was that they would be placed on Contacts in REGISTER requests.= So you can interpret the definitions in that context: that a request sent = to an AOR using callerprefs can affect the choice of which device the reque= st goes to according to the capabilities it wants. In that context audio, v= ideo, isfocus all make sense. > > Their use on Contacts in dialogs was derivative to that: because callerpr= ef support is optional, there is no guarantee that the device you reach via= callerprefs will have the capabilities you requested. So the values in the= contact help confirm what you got. > > Of course they have since been used other ways. And the descriptions of t= hem don't necessarily reflect that. IMO that is a defect due to the evoluti= on of use. > > I'm looking for the same sort of context for use with the feature-caps. > > In private discussion you indicated to me that you expected the feature c= aps to be grouped - with one of them giving the URI of the device that the = other tags apply to. I guess this would end up looking something like: > > Feature-Caps: *;g.uri=3D"sip:foo@example.com";audio > Feature-Caps: *;g.uri=3D"sip:bar@example.com";audio;video;isfocus > Feature-Caps: *;g.uri=3D"sip:baz@example.com";text > > (I'm making up g.uri for the example.) > > And then presumably somebody on the signaling path will "shop" in the fea= ture caps for the capabilities it wants, and then send a request to that UR= I, with the expectation that the UA responding will have those capabilities= . > >> The semantics should be no different than those of the corresponding ex= isting media feature tag if it is present in the Contact header. > > Note that 6809 says: > > When a SIP entity receives a SIP request, or response, that contains > one or more Feature-Caps header fields, the feature-capability > indicators in the header field inform the entity about the features > and capabilities supported by entities in the SIP message signaling > path. The procedure by which features and capabilities are invoked > are outside the scope of this specification and MUST be described by > individual feature-capability indicator specifications. > > A Feature-Caps header field value cannot convey the address of the > SIP entity that inserted the Feature-Caps header field. If > additional data about a supported feature needs to be conveyed, such > as the address of the SIP entity that indicated support of the > feature, then the feature definition needs to define a way to convey > that information as a value of the associated feature-capability > indicator. > > This was discussed at length while that RFC was under consideration. Yet = the definitions of the tags in *this* draft don't specify that. > >> The registration templates currently reference the RFC 3840 and the othe= r RFCs that define the other media feature tags that correspond to these fe= ature capability indicators. > > And those definitions were written to be understood in the context of 384= 0/3841. They make sense in that context, but not in *this* context. > > Thanks, > Paul > >> But if more explicit detail is required then I can add some more text o= r alternatively remove the less important ones if they are going to become = rat holes. The ones I regard as really important and urgent are sip.methods= , sip.extensions and sip.events the meaning of which I think should be quit= e clear. >> >> Andrew >> >> ----- Original Message ----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com >> >> Cc: rlb@ipv.sx ; adam@nostrum.com ; >> christer.holmberg@ericsson.com ; >> mary.ietf.barnes@gmail.com ; Paul Kyzivat >> >> Subject: Re: New sipcore draft submission >> draft-allen-sipcore-sip-tree-cap-indicators >> >> On 10/24/13 4:07 PM, Andrew Allen wrote: >>> >>> Paul >>> >>> Ok >>> >>> So we are basically where I thought we were at when I submitted the dra= ft. >>> >>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who= indicates interest) can have some offline discussion in Vancouver on wheth= er and how to progress this. >> >> As I indicated again on the sipcore list, I found the that the draft >> didn't explain nearly enough to allow meaningful use of these. >> I know you replied, and I will continue the conversation there. >> But I will be opposed to these until and unless the draft (and notably >> the descriptions of the tags) are clear about how one could figure out >> what can do in the presence of the tags that one couldn't do without >> them. AND, that the behavior that suggests doesn't "break" sip. (E.g., >> by advocating a new and incompatible way to do something.) >> >> We can continue this on the sipcore list. >> >> Thanks, >> Paul >> >>> Andrew >>> >>> ----- Original Message ----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >>> To: Andrew Allen; Gonzalo Camarillo >>> Cc: Richard Barnes (rlb@ipv.sx) ; Adam Roach >>> (adam@nostrum.com) ; Christer Holmberg >>> (christer.holmberg@ericsson.com) ; >>> Mary Barnes (mary.ietf.barnes@gmail.com) >>> Subject: Re: New sipcore draft submission >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> On 10/24/13 2:17 PM, Andrew Allen wrote: >>>> Paul >>>> >>>> That is fine. Although Mary in her reply to me seemed to indicate mayb= e there was a possibility to use some of the DISPATCH spare time for a SIPC= ORE session for this. Is that a possibility? >>>> >>>> I already replied to your post >>> >>> I discussed that with Adam. We decided we can't set a precedent to >>> spin up a session to discuss a draft that hasn't had substantial >>> (any) list discussion. >>> >>> But list discussion is always welcome. >>> >>> Sorry, >>> Paul >>> >>>> Andrew >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, October 24, 2013 1:31 PM >>>> To: Andrew Allen; Gonzalo Camarillo >>>> Cc: Richard Barnes (rlb@ipv.sx); Adam Roach (adam@nostrum.com); >>>> Christer Holmberg (christer.holmberg@ericsson.com) >>>> Subject: Re: New sipcore draft submission >>>> draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> Andrew, >>>> >>>> I spoke with Mary about it, and we concluded that dispatch isn't right= for this. (In addition to being clearly sipcore, it didn't meet the deadli= ne for dispatch.) I was wrong to encourage you that way. >>>> >>>> So no official live discussion in Vancouver. (But informal >>>> discussion >>>> fine.) >>>> >>>> I'll resend my private comments to the sipcore list to kickstart some = discussion there. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>>> I just emailed Mary asking for agenda time. Should I cancel that requ= est? >>>>> >>>>> -----Original Message----- >>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>> Sent: Thursday, October 24, 2013 1:00 PM >>>>> To: Paul Kyzivat >>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx); Adam Roach >>>>> (adam@nostrum.com); Christer Holmberg >>>>> (christer.holmberg@ericsson.com) >>>>> Subject: Re: New sipcore draft submission >>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>> >>>>> Hi Paul, >>>>> >>>>> given that you think this belongs to SIPCORE, I do not see the need t= o run it through DISPATCH. Please, start technical discussions on the draft= on the SIPCORE list. >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>>> Paul >>>>>>> >>>>>>> Thanks for reviewing the draft already and giving me early feedback= . >>>>>>> >>>>>>> My responses below inline (prepended with [AA). >>>>>>> >>>>>>> Can I ask the ADs to determine ASAP if this needs to go to >>>>>>> DISPATCH first or not. As outlined below my view is that it is >>>>>>> unnecessary for every little thing to go to DISPATCH as this just >>>>>>> creates additional delay and overhead. If it is to be discussed >>>>>>> in DISPATCH then I definitely would want agenda time atIETF#88 for = this. >>>>>> >>>>>> Having now seen Andrew's responses to my initial questions, I >>>>>> think this >>>>>> *needs* to be carefully considered by sipcore. IMO this has the >>>>>> potential to create a dialect of sip that is incompatible with >>>>>> normal usage. (Maybe IMS has already done that. But this will make >>>>>> it >>>>>> worse.) >>>>>> >>>>>> But if there is a desire to discuss it publicly in Vancouver then >>>>>> dispatch is the opportunity and so some discussion on the dispatch >>>>>> list in advance of that would be appropriate. >>>>>> >>>>>> I'll defer to the ADs on this. >>>>>> >>>>>> More inline. >>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx); Gonzalo Camarillo >>>>>>> (Gonzalo.Camarillo@ericsson.com); Adam Roach (adam@nostrum.com) >>>>>>> Subject: Re: New sipcore draft submission >>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>> >>>>>>> Andrew, >>>>>>> >>>>>>> On a legalistic note, its questionable to me whether this kind of >>>>>>> action falls within the scope of sipcore. OTOH, among existing >>>>>>> wgs, sipcore is probably the best suited to discuss the proposal. >>>>>>> We could take it to DISPATCH. I think DISPATCH has extra time in >>>>>>> its agenda for Vancouver, so that might be one option for you. >>>>>>> But then I don't know where dispatch would dispatch it. It may be >>>>>>> that AD sponsored is the best way to go. >>>>>>> >>>>>>> [AA] It seemed to me that sipcore was the right place. This draft >>>>>>> registers feature-capability indicators in a registry that was >>>>>>> created by a sipcore RFC (RFC 6809). You could in my view make an >>>>>>> argument that this should even have been done as part of RFC 6809. >>>>>> >>>>>> If this was just a matter of registering some new feature caps >>>>>> that were not controversial, then I don't think sipcore needs to be = involved. >>>>>> >>>>>> But as I mentioned above, I do consider these controversial. >>>>>> >>>>>>> Discussing it now on the dispatch list would be a good start >>>>>>> toward discussing it at the dispatch session. >>>>>>> >>>>>>> [AA] Can I ask the ADs to determine if this needs to go to >>>>>>> DISPATCH first or not. My view is that it is unnecessary for >>>>>>> every little thing to go to DISPATCH as this just creates additiona= l delay and overhead. >>>>>>> This just registers some indicators in an existing IANA registry >>>>>>> and is not (or should not be IMHO) a major project. >>>>>> >>>>>> To me this is a matter of whether you want to be opportunistic. >>>>>> If this went to dispatch I would now recommend that it be >>>>>> dispatched to sipcore. So its a matter of whether you want to talk >>>>>> about it in the dispatch meeting. >>>>>> >>>>>>> Regarding substance, this draft troubles me. It takes >>>>>>> feature-caps in exactly the direction that I found most >>>>>>> concerning about the mechanism in the first place. >>>>>>> >>>>>>> Your draft partitions the existing media feature tags into two >>>>>>> sets >>>>>>> - those that would be useful as feature-capability-indicators, >>>>>>> and those that aren't. But I see no explanation of the criteria >>>>>>> used to make this distinction, nor can I think of one. >>>>>>> >>>>>>> [AA] I based this decision on the following criteria: If a >>>>>>> feature tag was potentially at all useful for an intermediary to >>>>>>> indicate it then include it in the registry. The ones not >>>>>>> included are either directly associated with the user >>>>>>> (intermediaries are not directly associated with the user) or >>>>>>> would only ever have one value (e.g automata). I am not sure >>>>>>> that every feature-capability indicator proposed to be registered >>>>>>> is actually useful but then I don't think every media feature tag >>>>>>> registered by RFC 3840 is either (I doubt very much if there are >>>>>>> implementation using the sip.application or sip.control feature >>>>>>> tags). I don't think RFC 3840 goes into a lot of details >>>>>>> justifying of ever registered media feature tag and specifying >>>>>>> the details of how they would be used either. I am willing to >>>>>>> remove any feature-capability indicators that are controversial exc= ept that I think we definitely need sip.extensions, sip.methods and sip.eve= nts. >>>>>>> There is a significant overhead to writing an >>>>>> d progressing internet drafts so my view is lets register all that >>>>>> might be remotely useful in the same document. >>>>>> >>>>>> The judgement of "useful" is reasonable. But I still can't discern >>>>>> what the use is from the iana registration descriptions. >>>>>> >>>>>>> For the ones that you have requested feature capability >>>>>>> indicators, I cannot figure out what using them would mean. For >>>>>>> example, when I see isFocus on a Contact header I know I am in a >>>>>>> conference, and that I can subscribe to the conference event >>>>>>> package at the contact URI. If I see isFocus in a Feature-Caps head= er, what does it mean? >>>>>>> What can I do once I know this? >>>>>>> >>>>>>> Section 5.14 of this draft says: >>>>>>> >>>>>>> This Feature-capability indicator indicates that the i= ntermediary >>>>>>> is a conference server, also known as a focus, and is = capable of >>>>>>> mixing together the media for all calls to the same UR= I. >>>>>>> ... >>>>>>> Examples of typical use: A conference bridge >>>>>>> indicating that it >>>>>>> is a conference bridge and is capable of acting as >>>>>>> a conference >>>>>>> focus for this session. >>>>>>> >>>>>>> [AA] the presence of isfocus in a Feature-Caps header field means >>>>>>> that a UA can initiate a conference by sending a REFER request to >>>>>>> the intermediary to invite another user and create a multi user >>>>>>> conference from the 1-1 session. >>>>>>> >>>>>>> Note that Feature-Caps doesn't indicate which entity has this >>>>>>> capability, only that something does. And since this would >>>>>>> presumably only be used if it wasn't the UAC of the request, >>>>>>> sending a subscribe to the contact address of the UAC wouldn't make= sense. >>>>>>> >>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I >>>>>>> consider this application specific and so this would be included >>>>>>> in a feature tag registered in the global tree as stated in the >>>>>>> draft "RFC 6809 [1] provides that addresses of intermediaries can >>>>>>> be communicated as a value of an associated feature-capability >>>>>>> indicator so it would be appropriate to define feature capability >>>>>>> indicators as part of the global tree to communicate the GRUU of >>>>>>> the intermediary and hence this is outside the scope of this >>>>>>> document." - RFC 6809 states " If additional data about a >>>>>>> supported feature needs to be conveyed, such as the address of >>>>>>> the SIP entity that indicated support of the feature, then the >>>>>>> feature definition needs to define a way to convey that >>>>>>> information as a value of the associated feature-capability >>>>>>> indicator." However I think the SIP specific capability >>>>>>> indicators such as methods, extensions and events should >>>>>>> appropriately be registered in the SIP tree not as proprietary >>>>>>> indicator >>>>>> s in the global tree. >>>>>> >>>>>> So you have defined a sip tree feature tag that is only useful in >>>>>> conjunction with another feature tag from the global tree. >>>>>> And the description of this feature tag doesn't even mention that. >>>>>> >>>>>> And this all implies a completely non-standard call model - doing >>>>>> conferencing in a way inconsistent with RFC 4579. >>>>>> >>>>>> ISTM that if 4579 doesn't work for you then you should be back >>>>>> proposing extensions/revisions to it. >>>>>> >>>>>>> If there is a conference bridge in the signaling path, then I >>>>>>> would expect it to be the UAC. >>>>>>> >>>>>>> [AA] Although a "standard" way to invoke a conference is to send >>>>>>> a REFER to the other UAs to invite them to the conference focus, >>>>>>> in many deployments a scenario exists where a call involves an >>>>>>> IP-PBX or Telephony Application Server (TAS) that can act as a >>>>>>> focus for the conference. A participant of a call can then create >>>>>>> a conference by sending a REFER request in dialog to the IP-PBX >>>>>>> or TAS to use 3PCC to Invite other users to a conference. Reasons f= or this are 1. >>>>>>> Not all UAs support REFER, >>>>>> >>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), >>>>>> but it *could become* a focus. >>>>>> >>>>>> The concept that a dialog may contain intermediaries that can be >>>>>> addressed to do stuff is not part of any sip standard that I am >>>>>> aware of. I don't care too much as long as the "stuff" is >>>>>> application stuff that is outside the scope of sip. But when it is >>>>>> alternative ways to do stuff that sip supports, then I get upset. >>>>>> >>>>>>> 2. Many SBCs reject REFER requests going outside domains because >>>>>>> of the potential for charging fraud (referring to a premium rate >>>>>>> number >>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to join >>>>>>> the conference may be charged for initiating the call when the >>>>>>> scenario is that the initiator of the conference should be charged. >>>>>>> 4. No need to obtain and distribute conference URIs. >>>>>>> Problem is how to achieve the same behavior without dialog reuse >>>>>>> which has been deprecated by RFC 6665? >>>>>> >>>>>> Then maybe the problem needs to be brought up, and a standard >>>>>> solution proposed, rather than simply enabling a proprietary mechani= sm. >>>>>> >>>>>>> As another example, consider section 5.1: >>>>>>> >>>>>>> Descrition: >>>>>>> This Feature-capability indicator indicates that the i= ntermediary >>>>>>> supports audio as a streaming media type. >>>>>>> ... >>>>>>> Examples of typical use: An IP PBX indicating that = it is >>>>>>> capable of accepting and initiating sessions with a= udio as a >>>>>>> streaming media type. >>>>>>> >>>>>>> This definition *implies* an assumption about the working >>>>>>> environment >>>>>>> - one that AFAIK is new. It implies that you need to know that >>>>>>> intermediaries support a media type before you can use it. Would >>>>>>> it be bad if there were no intermediaries, and so none indicated th= is? >>>>>>> What if some intermediary *did* indicate support, but some other >>>>>>> doesn't, but doesn't indicate that it doesn't? >>>>>>> >>>>>>> Bottom line: how would the presence or absence of this feature >>>>>>> tag affect subsequent usage? >>>>>>> >>>>>>> [AA] The absence of the streaming types does not indicate that >>>>>>> the intermediary does not support the media type and SDP offer >>>>>>> answer will ultimately determine what can or cannot be used if >>>>>>> another session is initiated involving the intermediary. However >>>>>>> the presence of the media type in a Feature-caps header field >>>>>>> does explictly confirm that the intermediary does support the >>>>>>> media type and in the scenario where a UA has a choice of >>>>>>> multiple intermediaries it could use for a conference it might >>>>>>> choose to use the one that explicitly indicates it supports the med= ia types the UA wants to use. >>>>>> >>>>>> So the UA will be able to discover that *some* intermediary >>>>>> supports media it is interested in. And it can tell that *some* >>>>>> intermediary says it is a focus. It doesn't know if they are the sam= e intermediary. >>>>>> >>>>>> And then via some other feature tag it obtains the URI of *some* >>>>>> intermediary on the signaling path. Or maybe it gets more than one >>>>>> of these. >>>>>> >>>>>> It then makes a leap of faith and conflates all those things, to >>>>>> determine that the URI identifies a focus that supports this media t= ype. >>>>>> >>>>>> Even then, exactly what does that mean? It may or may not mean >>>>>> that it supports mixing that media type in a conference. >>>>>> >>>>>>> As I stated already I don't care that much about these streaming >>>>>>> media types. >>>>>> >>>>>>> I could go on, but this is enough for now. >>>>>>> >>>>>>> [AA] My motivation for this is that currently 3GPP are updating >>>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>>> >>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with >>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather >>>>>>> than forwarding it all the way to the remote UA. >>>>>> >>>>>> And 6665 deprecates dial reuse in most of those cases. >>>>>> Without dialog reuse, the intermediaries don't get an opportunity >>>>>> to intercept those. >>>>>> >>>>>>> In order to know that an intermediary supports the target dialog >>>>>>> mechanism needed for a REFER request sent outside the dialog to >>>>>>> work we need sip.extensions as a feature-capability indicator. In >>>>>>> order to know that the needed event package is supported by the >>>>>>> intermediary so we can SUBSCROBE outside the dialog to an >>>>>>> intermediary we need sip.events as a feature-capability indicator. >>>>>> >>>>>> Then I think you should be back here with a problem statement and >>>>>> a request for how to get sip to solve it. >>>>>> >>>>>> And you should touch base with Christer on this. He may have a >>>>>> different opinion on the relevance of feature-caps as a solution. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>>> >>>>>>>> I have submitted a new draft to sipcore to register a number of >>>>>>>> feature capability indicators in the SIP tree (based upon some >>>>>>>> of the existing SIP media feature tags). The draft can be found at= : >>>>>>>> >>>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators= -00. >>>>>>>> txt >>>>>>>> >>>>>>>> Since there will not be a sipcore session at IETF#88 can we >>>>>>>> have an offline discussion on how to progress this draft (which >>>>>>>> hopefully is fairly straightforward as it just registers feature >>>>>>>> capabilities indicators with IANA). I wouldn't want to have to >>>>>>>> wait until March next year for a decision on progressing this. >>>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>>> ---------------------------------------------------------------- >>>>>>>> --- >>>>>>>> - >>>>>>>> - This transmission (including any attachments) may contain >>>>>>>> confidential information, privileged material (including >>>>>>>> material protected by the solicitor-client or other applicable >>>>>>>> privileges), or constitute non-public information. Any use of >>>>>>>> this information by anyone other than the intended recipient is >>>>>>>> prohibited. If you have received this transmission in error, >>>>>>>> please immediately reply to the sender and delete this >>>>>>>> information from your system. Use, dissemination, distribution, >>>>>>>> or reproduction of this transmission by unintended recipients is n= ot authorized and may be unlawful. >>>>>>> >>>>>>> ----------------------------------------------------------------- >>>>>>> --- >>>>>>> - This transmission (including any attachments) may contain >>>>>>> confidential information, privileged material (including material >>>>>>> protected by the solicitor-client or other applicable >>>>>>> privileges), or constitute non-public information. Any use of >>>>>>> this information by anyone other than the intended recipient is >>>>>>> prohibited. If you have received this transmission in error, >>>>>>> please immediately reply to the sender and delete this >>>>>>> information from your system. Use, dissemination, distribution, >>>>>>> or reproduction of this transmission by unintended recipients is no= t authorized and may be unlawful. >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> -- This transmission (including any attachments) may contain >>>>> confidential information, privileged material (including material pro= tected by the solicitor-client or other applicable privileges), or constitu= te non-public information. Any use of this information by anyone other than= the intended recipient is prohibited. If you have received this transmissi= on in error, please immediately reply to the sender and delete this informa= tion from your system. Use, dissemination, distribution, or reproduction of= this transmission by unintended recipients is not authorized and may be un= lawful. >>>>> >>>>> >>>> >>>> -------------------------------------------------------------------- >>>> - This transmission (including any attachments) may contain >>>> confidential information, privileged material (including material prot= ected by the solicitor-client or other applicable privileges), or constitut= e non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this transmissio= n in error, please immediately reply to the sender and delete this informat= ion from your system. Use, dissemination, distribution, or reproduction of = this transmission by unintended recipients is not authorized and may be unl= awful. >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the solic= itor-client or other applicable privileges), or constitute non-public infor= mation. Any use of this information by anyone other than the intended recip= ient is prohibited. If you have received this transmission in error, please= immediately reply to the sender and delete this information from your syst= em. Use, dissemination, distribution, or reproduction of this transmission = by unintended recipients is not authorized and may be unlawful. >>> >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential i= nformation, privileged material (including material protected by the solici= tor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recipi= ent is prohibited. If you have received this transmission in error, please = immediately reply to the sender and delete this information from your syste= m. Use, dissemination, distribution, or reproduction of this transmission b= y unintended recipients is not authorized and may be unlawful. >> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B1C4F70E4ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

As a side note, you can also indicate a SIP method as a URI parameter:

 

sip:transfer@example.com;method=3Drefer

 

From: sipcore-bounces@ietf.org [sipcore-bou= nces@ietf.org] on behalf of Christer Holmberg [christer.holmberg@ericsson.c= om]
Sent: Friday, 25 October 2013 9:47 PM
To: Paul Kyzivat; Andrew Allen; SIPCORE
Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipc= ore-sip-tree-cap-indicators

Hi,

 

>> The next revi= sions will contain more details on what each FCI (as Christer now calls the= m means).
>>
>> If some are not well understood I will remove them from the draft = (i.e. drop  the rat holes)
>>
>> I think my email exchange with Christer clarifies the other points= .
>>
>> Does this represent in principle a way forward?
>
> Maybe. We'll have to see how it goes.
>
> The challenge is, I think, that you want to bring in a bunch of the 38= 40
> feature tags, and have them mean something akin to what they do as > feature tags when used as FCIs. But there needs to be some way to
> describe what *each* one means. It's not immediately clear to me how t= o
> do that.

As I said in another r= eply, I think that the FCIs that use the +sip.method etc FCIs need to d= escribe how they are used in conjunction.

 

Example:=

 

Feature-Caps: *;+g= .x;+sip.methods=3D"INVITE"

Feature-Caps: *;+g= .y;+sip.methods=3D"INVITE"

 

The FCI specifications= for +g.x and +g.y need to describe how they are used tog= ether with +sip.methods, if there is a relationship.

 

Otherwise +sip.met= hods only means that the entity that inserted the FCIs support "INVITE= ".

 

Regards,=

 

Christer=

 

 

 

 

 

> -----Original Mes= sage-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: Friday, October 25, 2013 10:06 AM
> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com
> Cc: rlb@ipv.sx; adam@nostrum.com; christer.holmberg@ericsson.com; mary= .ietf.barnes@gmail.com
> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree= -cap-indicators
>
> Andrew,
>
> (I see this is still on the private thread. I'll reply here, but this = exchange should probably be reposted to the sipcore list as part of the pub= lic discussion of the draft.)
>
> On 10/24/13 10:41 PM, Andrew Allen wrote:
>>
>> Paul
>>
>> I am happy to do a revision with more details on the semantics of = the capability indicators. However I don't think it should be held to a ver= y much higher bar than the details in RFC 3840 and the other media feature = tag RFCs regarding the meaning of those tags.
>
> Keep in mind that the driving force for the definition of feature tags= in 3840 was in support of callerprefs (3841). So the context for the use o= f feature tags was that they would be placed on Contacts in REGISTER reques= ts. So you can interpret the definitions in that context: that a request sent to an AOR using callerprefs can affec= t the choice of which device the request goes to according to the capabilit= ies it wants. In that context audio, video, isfocus all make sense.
>
> Their use on Contacts in dialogs was derivative to that: because calle= rpref support is optional, there is no guarantee that the device you reach = via callerprefs will have the capabilities you requested. So the values in = the contact help confirm what you got.
>
> Of course they have since been used other ways. And the descriptions o= f them don't necessarily reflect that. IMO that is a defect due to the evol= ution of use.
>
> I'm looking for the same sort of context for use with the feature-caps= .
>
> In private discussion you indicated to me that you expected the featur= e caps to be grouped - with one of them giving the URI of the device that t= he other tags apply to. I guess this would end up looking something like: >
>     Feature-Caps: *;g.uri=3D"sip:foo@example.= com";audio
>     Feature-Caps: *;g.uri=3D"sip:bar@example.= com";audio;video;isfocus
>     Feature-Caps: *;g.uri=3D"sip:baz@example.= com";text
>
> (I'm making up g.uri for the example.)
>
> And then presumably somebody on the signaling path will "shop&quo= t; in the feature caps for the capabilities it wants, and then send a reque= st to that URI, with the expectation that the UA responding will have those= capabilities.
>
>> The semantics should be no different than those of  the corre= sponding existing media  feature tag if it is present in the Contact h= eader.
>
> Note that 6809 says:
>
>      When a SIP entity receives a SIP request= , or response, that contains
>      one or more Feature-Caps header fields, = the feature-capability
>      indicators in the header field inform th= e entity about the features
>      and capabilities supported by entities i= n the SIP message signaling
>      path.  The procedure by which featu= res and capabilities are invoked
>      are outside the scope of this specificat= ion and MUST be described by
>      individual feature-capability indicator = specifications.
>
>      A Feature-Caps header field value cannot= convey the address of the
>      SIP entity that inserted the Feature-Cap= s header field.  If
>      additional data about a supported featur= e needs to be conveyed, such
>      as the address of the SIP entity that in= dicated support of the
>      feature, then the feature definition nee= ds to define a way to convey
>      that information as a value of the assoc= iated feature-capability
>      indicator.
>
> This was discussed at length while that RFC was under consideration. Y= et the definitions of the tags in *this* draft don't specify that.
>
>> The registration templates currently reference the RFC 3840 and th= e other RFCs that define the other media feature tags that correspond to th= ese feature capability indicators.
>
> And those definitions were written to be understood in the context of = 3840/3841. They make sense in that context, but not in *this* context.
>
>        Thanks,
>        Paul
>
>> But if more explicit detail is required then I can add some more t= ext  or alternatively remove the less important ones if they are going= to become rat holes. The ones I regard as really important and urgent are = sip.methods, sip.extensions and sip.events the meaning of which I think should be quite clear.
>>
>> Andrew
>>
>> ----- Original Message -----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com
>> <Gonzalo.Camarillo@ericsson.com>
>> Cc: rlb@ipv.sx <rlb@ipv.sx>; adam@nostrum.com <adam@nostr= um.com>;
>> christer.holmberg@ericsson.com <christer.holmberg@ericsson.com&= gt;;
>> mary.ietf.barnes@gmail.com <mary.ietf.barnes@gmail.com>; Pau= l Kyzivat
>> <pkyzivat@alum.mit.edu>
>> Subject: Re: New sipcore draft submission
>> draft-allen-sipcore-sip-tree-cap-indicators
>>
>> On 10/24/13 4:07 PM, Andrew Allen wrote:
>>>
>>> Paul
>>>
>>> Ok
>>>
>>> So we are basically where I thought we were at when I submitte= d the draft.
>>>
>>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone= else who indicates interest) can have some offline discussion in Vancouver= on whether and how to progress this.
>>
>> As I indicated again on the sipcore list, I found the that the dra= ft
>> didn't explain nearly enough to allow meaningful use of these.
>> I know you replied, and I will continue the conversation there. >> But I will be opposed to these until and unless the draft (and not= ably
>> the descriptions of the tags) are clear about how one could figure= out
>> what can do in the presence of the tags that one couldn't do witho= ut
>> them. AND, that the behavior that suggests doesn't "break&quo= t; sip. (E.g.,
>> by advocating a new and incompatible way to do something.)
>>
>> We can continue this on the sipcore list.
>>
>>       Thanks,
>>       Paul
>>
>>> Andrew
>>>
>>> ----- Original Message -----
>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Tim= e
>>> To: Andrew Allen; Gonzalo Camarillo <Gonzalo.Camarillo@eric= sson.com>
>>> Cc: Richard Barnes (rlb@ipv.sx) <rlb@ipv.sx>; Adam Roach=
>>> (adam@nostrum.com) <adam@nostrum.com>; Christer Holmberg=
>>> (christer.holmberg@ericsson.com) <christer.holmberg@ericsso= n.com>;
>>> Mary Barnes (mary.ietf.barnes@gmail.com) <mary.ietf.barnes@= gmail.com>
>>> Subject: Re: New sipcore draft submission
>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>
>>> On 10/24/13 2:17 PM, Andrew Allen wrote:
>>>> Paul
>>>>
>>>> That is fine. Although Mary in her reply to me seemed to i= ndicate maybe there was a possibility to use some of the DISPATCH spare tim= e for a SIPCORE session for this. Is that a possibility?
>>>>
>>>> I already replied to your post
>>>
>>> I discussed that with Adam. We decided we can't set a preceden= t to
>>> spin up a session to discuss a draft that hasn't had substanti= al
>>> (any) list discussion.
>>>
>>> But list discussion is always welcome.
>>>
>>>      Sorry,
>>>      Paul
>>>
>>>> Andrew
>>>>
>>>> -----Original Message-----
>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>> Sent: Thursday, October 24, 2013 1:31 PM
>>>> To: Andrew Allen; Gonzalo Camarillo
>>>> Cc: Richard Barnes (rlb@ipv.sx); Adam Roach (adam@nostrum.= com);
>>>> Christer Holmberg (christer.holmberg@ericsson.com)
>>>> Subject: Re: New sipcore draft submission
>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>
>>>> Andrew,
>>>>
>>>> I spoke with Mary about it, and we concluded that dispatch= isn't right for this. (In addition to being clearly sipcore, it didn't mee= t the deadline for dispatch.) I was wrong to encourage you that way.
>>>>
>>>> So no official live discussion in Vancouver. (But informal=
>>>> discussion
>>>> fine.)
>>>>
>>>> I'll resend my private comments to the sipcore list to kic= kstart some discussion there.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>> On 10/24/13 1:01 PM, Andrew Allen wrote:
>>>>> I just emailed Mary asking for agenda time. Should I c= ancel that request?
>>>>>
>>>>> -----Original Message-----
>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.co= m]
>>>>> Sent: Thursday, October 24, 2013 1:00 PM
>>>>> To: Paul Kyzivat
>>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx); Adam Ro= ach
>>>>> (adam@nostrum.com); Christer Holmberg
>>>>> (christer.holmberg@ericsson.com)
>>>>> Subject: Re: New sipcore draft submission
>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>
>>>>> Hi Paul,
>>>>>
>>>>> given that you think this belongs to SIPCORE, I do not= see the need to run it through DISPATCH. Please, start technical discussio= ns on the draft on the SIPCORE list.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Gonzalo
>>>>>
>>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote:
>>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote:
>>>>>>> Paul
>>>>>>>
>>>>>>> Thanks for reviewing the draft already and giv= ing me early feedback.
>>>>>>>
>>>>>>> My responses below inline (prepended with [AA)= .
>>>>>>>
>>>>>>> Can I ask the ADs to determine ASAP if this ne= eds to go to
>>>>>>> DISPATCH first or not. As outlined below my vi= ew is that it is
>>>>>>> unnecessary for every little thing to go to DI= SPATCH as this just
>>>>>>> creates additional delay and overhead. If it i= s to be discussed
>>>>>>> in DISPATCH then I definitely would want agend= a time atIETF#88 for this.
>>>>>>
>>>>>> Having now seen Andrew's responses to my initial q= uestions, I
>>>>>> think this
>>>>>> *needs* to be carefully considered by sipcore. IMO= this has the
>>>>>> potential to create a dialect of sip that is incom= patible with
>>>>>> normal usage. (Maybe IMS has already done that. Bu= t this will make
>>>>>> it
>>>>>> worse.)
>>>>>>
>>>>>> But if there is a desire to discuss it publicly in= Vancouver then
>>>>>> dispatch is the opportunity and so some discussion= on the dispatch
>>>>>> list in advance of that would be appropriate.
>>>>>>
>>>>>> I'll defer to the ADs on this.
>>>>>>
>>>>>> More inline.
>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM
>>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx);= Gonzalo Camarillo
>>>>>>> (Gonzalo.Camarillo@ericsson.com); Adam Roach (= adam@nostrum.com)
>>>>>>> Subject: Re: New sipcore draft submission
>>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>>
>>>>>>> Andrew,
>>>>>>>
>>>>>>> On a legalistic note, its questionable to me w= hether this kind of
>>>>>>> action falls within the scope of sipcore. OTOH= , among existing
>>>>>>> wgs, sipcore is probably the best suited to di= scuss the proposal.
>>>>>>> We could take it to DISPATCH. I think DISPATCH= has extra time in
>>>>>>> its agenda for Vancouver, so that might be one= option for you.
>>>>>>> But then I don't know where dispatch would dis= patch it. It may be
>>>>>>> that AD sponsored is the best way to go.
>>>>>>>
>>>>>>> [AA] It seemed to me that sipcore was the righ= t place. This draft
>>>>>>> registers feature-capability indicators in a r= egistry that was
>>>>>>> created by a sipcore RFC (RFC 6809). You could= in my view make an
>>>>>>> argument that this should even have been done = as part of RFC 6809.
>>>>>>
>>>>>> If this was just a matter of registering some new = feature caps
>>>>>> that were not controversial, then I don't think si= pcore needs to be involved.
>>>>>>
>>>>>> But as I mentioned above, I do consider these cont= roversial.
>>>>>>
>>>>>>> Discussing it now on the dispatch list would b= e a good start
>>>>>>> toward discussing it at the dispatch session.<= br> >>>>>>>
>>>>>>> [AA] Can I ask the ADs to determine if this ne= eds to go to
>>>>>>> DISPATCH first or not. My view is that it is u= nnecessary for
>>>>>>> every little thing to go to DISPATCH as this j= ust creates additional delay and overhead.
>>>>>>> This just registers some indicators in an exis= ting IANA registry
>>>>>>> and is not (or should not be IMHO) a major pro= ject.
>>>>>>
>>>>>> To me this is a matter of whether you want to be o= pportunistic.
>>>>>> If this went to dispatch I would now recommend tha= t it be
>>>>>> dispatched to sipcore. So its a matter of whether = you want to talk
>>>>>> about it in the dispatch meeting.
>>>>>>
>>>>>>> Regarding substance, this draft troubles me. I= t takes
>>>>>>> feature-caps in exactly the direction that I f= ound most
>>>>>>> concerning about the mechanism in the first pl= ace.
>>>>>>>
>>>>>>> Your draft partitions the existing media featu= re tags into two
>>>>>>> sets
>>>>>>> - those that would be useful as feature-capabi= lity-indicators,
>>>>>>> and those that aren't. But I see no explanatio= n of the criteria
>>>>>>> used to make this distinction, nor can I think= of one.
>>>>>>>
>>>>>>> [AA] I based this decision on the following cr= iteria: If a
>>>>>>> feature tag was potentially at all useful for = an intermediary to
>>>>>>> indicate it then include it in the registry. T= he ones not
>>>>>>> included are either directly associated with t= he user
>>>>>>> (intermediaries are not  directly associa= ted with the user) or
>>>>>>> would only ever have one value (e.g automata).=   I am not sure
>>>>>>> that every feature-capability indicator propos= ed to be registered
>>>>>>> is actually useful but then I don't think ever= y media feature tag
>>>>>>> registered by RFC 3840 is either (I doubt very= much if there are
>>>>>>> implementation using the sip.application or si= p.control feature
>>>>>>> tags). I don't think RFC 3840 goes into a lot = of details
>>>>>>> justifying of ever registered media feature ta= g and specifying
>>>>>>> the details of how they would be used either.&= nbsp; I am willing to
>>>>>>> remove any feature-capability indicators that = are controversial except that I think we definitely need sip.extensions, si= p.methods and sip.events.
>>>>>>> There is a significant overhead to writing an<= br> >>>>>> d progressing internet drafts so my view is lets r= egister all that
>>>>>> might be remotely useful in the same document.
>>>>>>
>>>>>> The judgement of "useful" is reasonable.= But I still can't discern
>>>>>> what the use is from the iana registration descrip= tions.
>>>>>>
>>>>>>> For the ones that you have requested feature c= apability
>>>>>>> indicators, I cannot figure out what using the= m would mean. For
>>>>>>> example, when I see isFocus on a Contact heade= r I know I am in a
>>>>>>> conference, and that I can subscribe to the co= nference event
>>>>>>> package at the contact URI. If I see isFocus i= n a Feature-Caps header, what does it mean?
>>>>>>> What can I do once I know this?
>>>>>>>
>>>>>>> Section 5.14 of this draft says:
>>>>>>>
>>>>>>>        = ;      This Feature-capability indicator indicates= that the intermediary
>>>>>>>        = ;      is a conference server, also known as a foc= us, and is capable of
>>>>>>>        = ;      mixing together the media for all calls to = the same URI.
>>>>>>> ...
>>>>>>>        = ;         Examples of typical use: = A conference bridge
>>>>>>> indicating that it
>>>>>>>        = ;         is a conference bridge an= d is capable of acting as
>>>>>>> a conference
>>>>>>>        = ;         focus for this session. >>>>>>>
>>>>>>> [AA] the presence of isfocus in a Feature-Caps= header field means
>>>>>>> that a UA can initiate a conference by sending= a REFER request to
>>>>>>> the intermediary to invite another user and cr= eate a multi user
>>>>>>> conference from the 1-1 session.
>>>>>>>
>>>>>>> Note that Feature-Caps doesn't indicate which = entity has this
>>>>>>> capability, only that something does. And sinc= e this would
>>>>>>> presumably only be used if it wasn't the UAC o= f the request,
>>>>>>> sending a subscribe to the contact address of = the UAC wouldn't make sense.
>>>>>>>
>>>>>>> [AA] Yes the GRUU of the intermediary would be= needed but I
>>>>>>> consider this application specific and so this= would be included
>>>>>>> in a feature tag registered in the global tree= as stated in the
>>>>>>> draft "RFC 6809 [1] provides that address= es of intermediaries can
>>>>>>> be communicated as a value of an associated fe= ature-capability
>>>>>>> indicator so it would be appropriate to define= feature capability
>>>>>>> indicators as part of the global tree to commu= nicate the GRUU of
>>>>>>> the intermediary and hence this is outside the= scope of this
>>>>>>> document."  - RFC 6809 states "= If additional data about a
>>>>>>> supported feature needs to be conveyed, such a= s the address of
>>>>>>> the SIP entity that indicated support of the f= eature, then the
>>>>>>> feature definition needs to define a way to co= nvey that
>>>>>>> information as a value of the associated featu= re-capability
>>>>>>> indicator." However I think the SIP speci= fic capability
>>>>>>> indicators such as methods, extensions and eve= nts should
>>>>>>> appropriately be registered in the SIP tree no= t as proprietary
>>>>>>> indicator
>>>>>> s in the global tree.
>>>>>>
>>>>>> So you have defined a sip tree feature tag that is= only useful in
>>>>>> conjunction with another feature tag from the glob= al tree.
>>>>>> And the description of this feature tag doesn't ev= en mention that.
>>>>>>
>>>>>> And this all implies a completely non-standard cal= l model - doing
>>>>>> conferencing in a way inconsistent with RFC 4579.<= br> >>>>>>
>>>>>> ISTM that if 4579 doesn't work for you then you sh= ould be back
>>>>>> proposing extensions/revisions to it.
>>>>>>
>>>>>>> If there is a conference bridge in the signali= ng path, then I
>>>>>>> would expect it to be the UAC.
>>>>>>>
>>>>>>> [AA] Although a "standard" way to in= voke a conference is to send
>>>>>>> a REFER to the other UAs to invite them to the= conference focus,
>>>>>>> in many deployments a scenario exists where a = call involves an
>>>>>>> IP-PBX or Telephony Application Server (TAS) t= hat can act as a
>>>>>>> focus for the conference. A participant of a c= all can then create
>>>>>>> a conference by sending a REFER request in dia= log to the IP-PBX
>>>>>>> or TAS to use 3PCC to Invite other users to a = conference. Reasons for this are 1.
>>>>>>> Not all UAs support REFER,
>>>>>>
>>>>>> So you are saying the intermediary isn't a focus (= its a B2BUA),
>>>>>> but it *could become* a focus.
>>>>>>
>>>>>> The concept that a dialog may contain intermediari= es that can be
>>>>>> addressed to do stuff is not part of any sip stand= ard that I am
>>>>>> aware of. I don't care too much as long as the &qu= ot;stuff" is
>>>>>> application stuff that is outside the scope of sip= . But when it is
>>>>>> alternative ways to do stuff that sip supports, th= en I get upset.
>>>>>>
>>>>>>> 2. Many SBCs reject REFER requests going outsi= de domains because
>>>>>>> of the potential for charging fraud (referring= to a premium rate
>>>>>>> number
>>>>>>> etc) 3. A User receiving a REFER and then usin= g an INVITE to join
>>>>>>> the conference may be charged for initiating&n= bsp; the call when the
>>>>>>> scenario is that the initiator of the conferen= ce should be charged.
>>>>>>> 4. No need to obtain and distribute conference= URIs.
>>>>>>> Problem is how to achieve the same behavior wi= thout dialog reuse
>>>>>>> which has been deprecated by RFC 6665?
>>>>>>
>>>>>> Then maybe the problem needs to be brought up, and= a standard
>>>>>> solution proposed, rather than simply enabling a p= roprietary mechanism.
>>>>>>
>>>>>>> As another example, consider section 5.1:
>>>>>>>
>>>>>>>        = ;      Descrition:
>>>>>>>        = ;      This Feature-capability indicator indicates= that the intermediary
>>>>>>>        = ;      supports audio as a streaming media type. >>>>>>> ...
>>>>>>>        = ;         Examples of typical use: = An IP PBX indicating that it is
>>>>>>>        = ;         capable of accepting and = initiating sessions with audio as a
>>>>>>>        = ;         streaming media type.
>>>>>>>
>>>>>>> This definition *implies* an assumption about = the working
>>>>>>> environment
>>>>>>> - one that AFAIK is new. It implies that you n= eed to know that
>>>>>>> intermediaries support a media type before you= can use it. Would
>>>>>>> it be bad if there were no intermediaries, and= so none indicated this?
>>>>>>> What if some intermediary *did* indicate suppo= rt, but some other
>>>>>>> doesn't, but doesn't indicate that it doesn't?=
>>>>>>>
>>>>>>> Bottom line: how would the presence or absence= of this feature
>>>>>>> tag affect subsequent usage?
>>>>>>>
>>>>>>> [AA] The absence of the streaming types does n= ot indicate that
>>>>>>> the intermediary does not support the media ty= pe and SDP offer
>>>>>>> answer will ultimately determine what can or c= annot be used if
>>>>>>> another session is initiated involving the int= ermediary. However
>>>>>>> the presence of the media type in a Feature-ca= ps header field
>>>>>>> does explictly confirm that the intermediary d= oes support the
>>>>>>> media type and in the scenario where a UA has = a choice of
>>>>>>> multiple intermediaries it could use for a con= ference it might
>>>>>>> choose to use the one that explicitly indicate= s it supports the media types the UA wants to use.
>>>>>>
>>>>>> So the UA will be able to discover that *some* int= ermediary
>>>>>> supports media it is interested in. And it can tel= l that *some*
>>>>>> intermediary says it is a focus. It doesn't know i= f they are the same intermediary.
>>>>>>
>>>>>> And then via some other feature tag it obtains the= URI of *some*
>>>>>> intermediary on the signaling path. Or maybe it ge= ts more than one
>>>>>> of these.
>>>>>>
>>>>>> It then makes a leap of faith and conflates all th= ose things, to
>>>>>> determine that the URI identifies a focus that sup= ports this media type.
>>>>>>
>>>>>> Even then, exactly what does that mean? It may or = may not mean
>>>>>> that it supports mixing that media type in a confe= rence.
>>>>>>
>>>>>>> As I stated already I don't care that much abo= ut these streaming
>>>>>>> media types.
>>>>>>
>>>>>>> I could go on, but this is enough for now.
>>>>>>>
>>>>>>> [AA] My motivation for this is that currently = 3GPP are updating
>>>>>>> their specifications to use RFC 6665 instead o= f RFC 3265.
>>>>>>
>>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE = and REFER with
>>>>>>> intermediaries accepting the REFER or SUBSCRIB= E request rather
>>>>>>> than forwarding it all the way to the remote U= A.
>>>>>>
>>>>>> And 6665 deprecates dial reuse in most of those ca= ses.
>>>>>> Without dialog reuse, the intermediaries don't get= an opportunity
>>>>>> to intercept those.
>>>>>>
>>>>>>> In order to know that an intermediary supports= the target dialog
>>>>>>> mechanism  needed for a REFER request sen= t outside the dialog to
>>>>>>> work we need sip.extensions as a feature-capab= ility indicator. In
>>>>>>> order to know that the needed event package is= supported by the
>>>>>>> intermediary so we can SUBSCROBE outside the d= ialog to an
>>>>>>> intermediary we need sip.events as a feature-c= apability indicator.
>>>>>>
>>>>>> Then I think you should be back here with a proble= m statement and
>>>>>> a request for how to get sip to solve it.
>>>>>>
>>>>>> And you should touch base with Christer on this. H= e may have a
>>>>>> different opinion on the relevance of feature-caps= as a solution.
>>>>>>
>>>>>>        &nb= sp; Thanks,
>>>>>>        &nb= sp; Paul
>>>>>>
>>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote:
>>>>>>>> Adam, Paul, Richard, Gonzalo
>>>>>>>>
>>>>>>>> I have submitted a new draft to sipcore&nb= sp; to register a number of
>>>>>>>> feature capability indicators in the SIP t= ree (based upon some
>>>>>>>> of the existing SIP media feature tags). T= he draft can be found at:
>>>>>>>>
>>>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00.<= br> >>>>>>>> txt
>>>>>>>>
>>>>>>>> Since there will not be a sipcore session = at IETF#88  can we
>>>>>>>> have an offline discussion on how to progr= ess this draft (which
>>>>>>>> hopefully is fairly straightforward as it = just registers feature
>>>>>>>> capabilities indicators with IANA). I woul= dn't want to have to
>>>>>>>> wait until March next year for a decision = on progressing this.
>>>>>>>>
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>> ------------------------------------------= ----------------------
>>>>>>>> ---
>>>>>>>> -
>>>>>>>> - This transmission (including any attachm= ents) may contain
>>>>>>>> confidential information, privileged mater= ial (including
>>>>>>>> material protected by the solicitor-client= or other applicable
>>>>>>>> privileges), or constitute non-public info= rmation. Any use of
>>>>>>>> this information by anyone other than the = intended recipient is
>>>>>>>> prohibited. If you have received this tran= smission in error,
>>>>>>>> please immediately reply to the sender and= delete this
>>>>>>>> information from your system. Use, dissemi= nation, distribution,
>>>>>>>> or reproduction of this transmission by un= intended recipients is not authorized and may be unlawful.
>>>>>>>
>>>>>>> ----------------------------------------------= -------------------
>>>>>>> ---
>>>>>>> - This transmission (including any attachments= ) may contain
>>>>>>> confidential information, privileged material = (including material
>>>>>>> protected by the solicitor-client or other app= licable
>>>>>>> privileges), or constitute non-public informat= ion. Any use of
>>>>>>> this information by anyone other than the inte= nded recipient is
>>>>>>> prohibited. If you have received this transmis= sion in error,
>>>>>>> please immediately reply to the sender and del= ete this
>>>>>>> information from your system. Use, disseminati= on, distribution,
>>>>>>> or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------= -------------
>>>>> -- This transmission (including any attachments) may c= ontain
>>>>> confidential information, privileged material (includi= ng material protected by the solicitor-client or other applicable privilege= s), or constitute non-public information. Any use of this information by an= yone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, disseminat= ion, distribution, or reproduction of this transmission by unintended recip= ients is not authorized and may be unlawful.
>>>>>
>>>>>
>>>>
>>>> ----------------------------------------------------------= ----------
>>>> - This transmission (including any attachments) may contai= n
>>>> confidential information, privileged material (including m= aterial protected by the solicitor-client or other applicable privileges), = or constitute non-public information. Any use of this information by anyone= other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, disseminat= ion, distribution, or reproduction of this transmission by unintended recip= ients is not authorized and may be unlawful.
>>>>
>>>>
>>>
>>> --------------------------------------------------------------= -------
>>> This transmission (including any attachments) may contain conf= idential information, privileged material (including material protected by = the solicitor-client or other applicable privileges), or constitute non-pub= lic information. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>
>>>
>>
>> ------------------------------------------------------------------= ---
>> This transmission (including any attachments) may contain confiden= tial information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute non-public = information. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>
>>
>
> ---------------------------------------------------------------------<= br> > This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the soli= citor-client or other applicable privileges), or constitute non-public info= rmation. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>
>

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--_000_7594FB04B1934943A5C02806D1A2204B1C4F70E4ESESSMB209erics_-- From christer.holmberg@ericsson.com Fri Oct 25 11:57:21 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FC011E8176 for ; Fri, 25 Oct 2013 11:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WkJL4BKmaYb for ; Fri, 25 Oct 2013 11:57:16 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 47E5E11E81C5 for ; Fri, 25 Oct 2013 11:57:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-0d-526abf08d210 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C6.57.16099.80FBA625; Fri, 25 Oct 2013 20:57:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Fri, 25 Oct 2013 20:57:12 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0bMClIxO5JTMPUCXBjIMGRWWSJoFwtbsgAABy1o= Date: Fri, 25 Oct 2013 18:57:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> In-Reply-To: <526ABD4B.1030404@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4F70FFESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+JvjS7H/qwgg5uH+C1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjxpeT7AVfnrNWNEz7z9LAuPsnSxcjB4eE gInErh1+XYycQKaYxIV769m6GLk4hAQOM0q83PudCcJZwihx6+pNsAY2AQuJ7n/aIA0iAoES V5dMYAaxhQUSJV5dmcEMEU+SuLnhHiNIuYiAlcTvhTogYRYBVYlDFz6wgdi8Ar4Sd3duYIQY /5FRorNnIliCU0BHYlfDLUYQmxHooO+n1jCB2MwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1gh bCWJHxsusUDU50scff4SapmgxMmZT1gmMIrMQjJqFpKyWUjKIOIGEu/PzWeGsLUlli18DWXr S2z8cpZxFtBrzALWEveXVCArWcDIsYqRPTcxMye93HATIzCmDm75rbuD8dQ5kUOM0hwsSuK8 H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgDF+74uRK/x7BGHE+7oQd/zXDb5lfChZk 8z34RGNN1YI3BVdu/tTn2JTD3KLXse5NrrD7lYxnhvuf965qiDrpOVWcXcH8+ocnq64ELoi8 I56hKb5jw9ptyn/+r16acvDkcYWqb7vSckRPv/zg3RJw6O/X9nftO7UPcSzayFk1L/qvtb79 zT2zWpVYijMSDbWYi4oTAc79KmZ3AgAA Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 18:57:21 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4F70FFESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, .... >> /Example:/ >> >> I support the find-Paul feature, and I insert a FCI: >> >> Feature-Caps: *, +g.find-paul=3D"sip:pkyzivat@alum.mit.edu" >> >> Now, in this case the address does NOT point to my entity, but to Paul's >> entity. My entity supports a feature, which provides Paul's address. >> >> So, if the FCI says: >> >> Feature-Caps: *, >> +g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.methods=3D"invite" >> >> ...it doesn't automatically mean that I can contact Paul using INVITE. >> By default it means that MY entity supports the INVITE method - which >> from the find-paul feature perspective is useless information. >> >> So, in the FCI specification for +g.find-paul, I would have to >> explictily describe how the FCI works in conjunction with other FCIs. I >> would have to explicitly say that, when used together +sip.methods, the >> +sip.methods indicates which SIP methods I can use to contact Paul >> (using the address provide in the +g.find-paul FCI). > > So far I agree. > > But suppose there is also a find-christer FCI. So we have: > > Feature-Caps: * > ;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu" > ;+g.find-paul=3D"sip:christer.holmberg@ericsson.com" > ;+sip.methods=3D"invite" > > And both find-paul and find-christer want to define the use of other > FCIs. Then things start to become ambiguous. > > Should the description of find-paul specify what other FCIs "pertain" to > it? Or should the description of sip.methods specify what FCI(s) provide > the address at which it applies? Or both? What if paul and christer > support different methods? In that case you would need to have two different Feature-Caps header field= s: Feature-Caps: *;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.methods= =3D"invite" Feature-Caps: *;+g.find-paul=3D"sip:christer.holmberg@ericsson.com";+si= p.methods=3D"message" In your example you had two instances of the same FCI (is that even allowed= ?), but there could also have been a case with two different FCIs, both usi= ng +sip.methods, in which case you may have to put them into separate Featu= re-Caps header fields. These things would have to be clearly specified. Regards, Christer > Section 5.3.8 in RFC 6809 also says: > > "If there is additional information about the feature-capability > indicator, it is recommended to describe such information. It ca= n > include, for example, *names of related feature-capability > indicators*." > > So, in your case, I think the +g.3gpp.see_trans FCI specifiction would > have to specify how the FCI is used in conjuntion with other FCIs, > including the +sip.method FCI. > > Something like: "When the session transfer request is sent to the > address indicated by the FCI value, the +sip.method FCI indicates which > SIP methods can be used." > > Regards, > > Christer > > > > *From*: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > *Sent*: Friday, October 25, 2013 12:01 PM Central Standard Time > *To*: Andrew Allen; Paul Kyzivat ; Gonzalo > Camarillo > *Cc*: rlb@ipv.sx ; adam@nostrum.com ; > mary.ietf.barnes@gmail.com > *Subject*: RE: New sipcore draft submission > draft-allen-sipcore-sip-tree-cap-indicators > > Hi, > >>I think we can have an FCI > >> > >>Feature-Caps: *;+g.3ggp.sess_trans=3D=94sip:foo@example.com;gr=94 > >> > >>Indicating that the entity supports 3GPP session transfer and the address= where you send the session transfer request is sip:foo@example.com;gr > > Correct. The FCI itself indicates support of session transfer feature, > and the FCI value indicates the address associatd with the feature. > >>Also if I have: > >> > >>Feature-Caps: *;+g.3ggp.sess_trans=3Dsip:foo@example.com;gr; +sip.extensi= ons=3D=94replaces, tdialog=94; > +sip.methods=3D=94invite, refer, bye, options, update, prack=94 > >> > >> This means the entity supports 3GPP session transfer and the address whe= re you send the session transfer request is sip:foo@example.com;gr ... > > Correct. > >> ...supports the replaces and target dialog extensions and supports the f= ollowing methods - invite, refer, bye, options, update, prack. > > Technically, what it means is that there is *AN* entity which supports > the features listed above, and the address is where you are to send the > session transfer request in order to trigger the 3GPP session transfer > feature. > > Regards, > > Christer > > *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] > *Sent:* Friday, October 25, 2013 10:25 AM > *To:* Paul Kyzivat; Andrew Allen; Gonzalo Camarillo > *Cc:* rlb@ipv.sx; adam@nostrum.com; mary.ietf.barnes@gmail.com > *Subject:* RE: New sipcore draft submission > draft-allen-sipcore-sip-tree-cap-indicators > > Hi, > > As Paul said, if one needs to provide address information associated > with a FCI, the address information cannot be a FCI of its own. It needs > to be a value of the FCI for which it is associated. > > Something like: > > Feature-Caps: *;+audio=3D"sip:foo@example.com" > > (Also note that the "+" sign is mandatory for all FCIs - no matter which > registry tree they belong to) > > Regards, > > Christer > > ------------------------------------------------------------------------ > > *From:*Paul Kyzivat [pkyzivat@alum.mit.edu] > *Sent:* Friday, 25 October 2013 5:06 PM > *To:* Andrew Allen; Gonzalo Camarillo > *Cc:* rlb@ipv.sx ; adam@nostrum.com > ; Christer Holmberg; mary.ietf.barnes@gmail.com > > *Subject:* Re: New sipcore draft submission > draft-allen-sipcore-sip-tree-cap-indicators > > Andrew, > > (I see this is still on the private thread. I'll reply here, but this > exchange should probably be reposted to the sipcore list as part of the > public discussion of the draft.) > > On 10/24/13 10:41 PM, Andrew Allen wrote: >> >> Paul >> >> I am happy to do a revision with more details on the semantics of the ca= pability indicators. However I don't think it should be held to a very much= higher bar than the details in RFC 3840 and the other media feature tag RF= Cs regarding the meaning of those tags. > > Keep in mind that the driving force for the definition of feature tags > in 3840 was in support of callerprefs (3841). So the context for the use > of feature tags was that they would be placed on Contacts in REGISTER > requests. So you can interpret the definitions in that context: that a > request sent to an AOR using callerprefs can affect the choice of which > device the request goes to according to the capabilities it wants. In > that context audio, video, isfocus all make sense. > > Their use on Contacts in dialogs was derivative to that: because > callerpref support is optional, there is no guarantee that the device > you reach via callerprefs will have the capabilities you requested. So > the values in the contact help confirm what you got. > > Of course they have since been used other ways. And the descriptions of > them don't necessarily reflect that. IMO that is a defect due to the > evolution of use. > > I'm looking for the same sort of context for use with the feature-caps. > > In private discussion you indicated to me that you expected the feature > caps to be grouped - with one of them giving the URI of the device that > the other tags apply to. I guess this would end up looking something like= : > > Feature-Caps: *;g.uri=3D"sip:foo@example.com";audio > Feature-Caps: *;g.uri=3D"sip:bar@example.com";audio;video;isfocus > Feature-Caps: *;g.uri=3D"sip:baz@example.com";text > > (I'm making up g.uri for the example.) > > And then presumably somebody on the signaling path will "shop" in the > feature caps for the capabilities it wants, and then send a request to > that URI, with the expectation that the UA responding will have those > capabilities. > >> The semantics should be no different than those of the corresponding ex= isting media feature tag if it is present in the Contact header. > > Note that 6809 says: > > When a SIP entity receives a SIP request, or response, that contains > one or more Feature-Caps header fields, the feature-capability > indicators in the header field inform the entity about the features > and capabilities supported by entities in the SIP message signaling > path. The procedure by which features and capabilities are invoked > are outside the scope of this specification and MUST be described by > individual feature-capability indicator specifications. > > A Feature-Caps header field value cannot convey the address of the > SIP entity that inserted the Feature-Caps header field. If > additional data about a supported feature needs to be conveyed, such > as the address of the SIP entity that indicated support of the > feature, then the feature definition needs to define a way to convey > that information as a value of the associated feature-capability > indicator. > > This was discussed at length while that RFC was under consideration. Yet > the definitions of the tags in *this* draft don't specify that. > >> The registration templates currently reference the RFC 3840 and the othe= r RFCs that define the other media feature tags that correspond to these fe= ature capability indicators. > > And those definitions were written to be understood in the context of > 3840/3841. They make sense in that context, but not in *this* context. > > Thanks, > Paul > >> But if more explicit detail is required then I can add some more text o= r alternatively remove the less important ones if they are going to become = rat holes. The ones I regard as really important and urgent are sip.methods= , sip.extensions and sip.events the meaning of which I think should be qui= te clear. >> >> Andrew >> >> ----- Original Message ----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >> To: Andrew Allen;Gonzalo.Camarillo@ericsson.com > > >> Cc:rlb@ipv.sx >; > adam@nostrum.com >; christer.holmberg@ericsson.com > >; mary.ietf.barnes@gmail.com > >; Paul Kyzivat > > >> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-c= ap-indicators >> >> On 10/24/13 4:07 PM, Andrew Allen wrote: >>> >>> Paul >>> >>> Ok >>> >>> So we are basically where I thought we were at when I submitted the dra= ft. >>> >>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who= indicates interest) can have some offline discussion in Vancouver on wheth= er and how to progress this. >> >> As I indicated again on the sipcore list, I found the that the draft >> didn't explain nearly enough to allow meaningful use of these. >> I know you replied, and I will continue the conversation there. >> But I will be opposed to these until and unless the draft (and notably >> the descriptions of the tags) are clear about how one could figure out >> what can do in the presence of the tags that one couldn't do without >> them. AND, that the behavior that suggests doesn't "break" sip. (E.g., >> by advocating a new and incompatible way to do something.) >> >> We can continue this on the sipcore list. >> >> Thanks, >> Paul >> >>> Andrew >>> >>> ----- Original Message ----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >>> To: Andrew Allen; Gonzalo Camarillo > >>> Cc: Richard Barnes (rlb@ipv.sx ) >; Adam > Roach (adam@nostrum.com ) >; Christer Holmberg > (christer.holmberg@ericsson.com ) > >; Mary Barnes > (mary.ietf.barnes@gmail.com ) < > mary.ietf.barnes@gmail.com > >>> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-= cap-indicators >>> >>> On 10/24/13 2:17 PM, Andrew Allen wrote: >>>> Paul >>>> >>>> That is fine. Although Mary in her reply to me seemed to indicate mayb= e there was a possibility to use some of the DISPATCH spare time for a SIPC= ORE session for this. Is that a possibility? >>>> >>>> I already replied to your post >>> >>> I discussed that with Adam. We decided we can't set a precedent to spin >>> up a session to discuss a draft that hasn't had substantial (any) list >>> discussion. >>> >>> But list discussion is always welcome. >>> >>> Sorry, >>> Paul >>> >>>> Andrew >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, October 24, 2013 1:31 PM >>>> To: Andrew Allen; Gonzalo Camarillo >>>> Cc: Richard Barnes (rlb@ipv.sx ); Adam Roach (adam@= nostrum.com > ); Christer Holmberg > (christer.holmberg@ericsson.com ) >>>> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree= -cap-indicators >>>> >>>> Andrew, >>>> >>>> I spoke with Mary about it, and we concluded that dispatch isn't right= for this. (In addition to being clearly sipcore, it didn't meet the deadli= ne for dispatch.) I was wrong to encourage you that way. >>>> >>>> So no official live discussion in Vancouver. (But informal discussion >>>> fine.) >>>> >>>> I'll resend my private comments to the sipcore list to kickstart some = discussion there. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>>> I just emailed Mary asking for agenda time. Should I cancel that requ= est? >>>>> >>>>> -----Original Message----- >>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>> Sent: Thursday, October 24, 2013 1:00 PM >>>>> To: Paul Kyzivat >>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx ); Ad= am Roach >>>>> (adam@nostrum.com ); Christer Holmberg > (christer.holmberg@ericsson.com ) >>>>> Subject: Re: New sipcore draft submission >>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>> >>>>> Hi Paul, >>>>> >>>>> given that you think this belongs to SIPCORE, I do not see the need t= o run it through DISPATCH. Please, start technical discussions on the draft= on the SIPCORE list. >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>>> Paul >>>>>>> >>>>>>> Thanks for reviewing the draft already and giving me early feedback= . >>>>>>> >>>>>>> My responses below inline (prepended with [AA). >>>>>>> >>>>>>> Can I ask the ADs to determine ASAP if this needs to go to DISPATCH >>>>>>> first or not. As outlined below my view is that it is unnecessary >>>>>>> for every little thing to go to DISPATCH as this just creates >>>>>>> additional delay and overhead. If it is to be discussed in DISPATCH >>>>>>> then I definitely would want agenda time atIETF#88 for this. >>>>>> >>>>>> Having now seen Andrew's responses to my initial questions, I think >>>>>> this >>>>>> *needs* to be carefully considered by sipcore. IMO this has the >>>>>> potential to create a dialect of sip that is incompatible with norma= l >>>>>> usage. (Maybe IMS has already done that. But this will make it >>>>>> worse.) >>>>>> >>>>>> But if there is a desire to discuss it publicly in Vancouver then >>>>>> dispatch is the opportunity and so some discussion on the dispatch >>>>>> list in advance of that would be appropriate. >>>>>> >>>>>> I'll defer to the ADs on this. >>>>>> >>>>>> More inline. >>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx ); = Gonzalo Camarillo >>>>>>> (Gonzalo.Camarillo@ericsson.com ); > Adam Roach (adam@nostrum.com ) >>>>>>> Subject: Re: New sipcore draft submission >>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>> >>>>>>> Andrew, >>>>>>> >>>>>>> On a legalistic note, its questionable to me whether this kind of >>>>>>> action falls within the scope of sipcore. OTOH, among existing wgs, >>>>>>> sipcore is probably the best suited to discuss the proposal. We >>>>>>> could take it to DISPATCH. I think DISPATCH has extra time in its >>>>>>> agenda for Vancouver, so that might be one option for you. But then >>>>>>> I don't know where dispatch would dispatch it. It may be that AD >>>>>>> sponsored is the best way to go. >>>>>>> >>>>>>> [AA] It seemed to me that sipcore was the right place. This draft >>>>>>> registers feature-capability indicators in a registry that was >>>>>>> created by a sipcore RFC (RFC 6809). You could in my view make an >>>>>>> argument that this should even have been done as part of RFC 6809. >>>>>> >>>>>> If this was just a matter of registering some new feature caps that >>>>>> were not controversial, then I don't think sipcore needs to be invol= ved. >>>>>> >>>>>> But as I mentioned above, I do consider these controversial. >>>>>> >>>>>>> Discussing it now on the dispatch list would be a good start toward >>>>>>> discussing it at the dispatch session. >>>>>>> >>>>>>> [AA] Can I ask the ADs to determine if this needs to go to DISPATCH >>>>>>> first or not. My view is that it is unnecessary for every little >>>>>>> thing to go to DISPATCH as this just creates additional delay and o= verhead. >>>>>>> This just registers some indicators in an existing IANA registry an= d >>>>>>> is not (or should not be IMHO) a major project. >>>>>> >>>>>> To me this is a matter of whether you want to be opportunistic. >>>>>> If this went to dispatch I would now recommend that it be dispatched >>>>>> to sipcore. So its a matter of whether you want to talk about it in >>>>>> the dispatch meeting. >>>>>> >>>>>>> Regarding substance, this draft troubles me. It takes feature-caps >>>>>>> in exactly the direction that I found most concerning about the >>>>>>> mechanism in the first place. >>>>>>> >>>>>>> Your draft partitions the existing media feature tags into two sets >>>>>>> - those that would be useful as feature-capability-indicators, and >>>>>>> those that aren't. But I see no explanation of the criteria used to >>>>>>> make this distinction, nor can I think of one. >>>>>>> >>>>>>> [AA] I based this decision on the following criteria: If a feature >>>>>>> tag was potentially at all useful for an intermediary to indicate i= t >>>>>>> then include it in the registry. The ones not included are either >>>>>>> directly associated with the user (intermediaries are not directly >>>>>>> associated with the user) or would only ever have one value (e.g >>>>>>> automata). I am not sure that every feature-capability indicator >>>>>>> proposed to be registered is actually useful but then I don't think >>>>>>> every media feature tag registered by RFC 3840 is either (I doubt >>>>>>> very much if there are implementation using the sip.application or >>>>>>> sip.control feature tags). I don't think RFC 3840 goes into a lot o= f >>>>>>> details justifying of ever registered media feature tag and >>>>>>> specifying the details of how they would be used either. I am >>>>>>> willing to remove any feature-capability indicators that are >>>>>>> controversial except that I think we definitely need sip.extensions= , sip.methods and sip.events. >>>>>>> There is a significant overhead to writing an >>>>>> d progressing internet drafts so my view is lets register all that >>>>>> might be remotely useful in the same document. >>>>>> >>>>>> The judgement of "useful" is reasonable. But I still can't discern >>>>>> what the use is from the iana registration descriptions. >>>>>> >>>>>>> For the ones that you have requested feature capability indicators, >>>>>>> I cannot figure out what using them would mean. For example, when I >>>>>>> see isFocus on a Contact header I know I am in a conference, and >>>>>>> that I can subscribe to the conference event package at the contact >>>>>>> URI. If I see isFocus in a Feature-Caps header, what does it mean? >>>>>>> What can I do once I know this? >>>>>>> >>>>>>> Section 5.14 of this draft says: >>>>>>> >>>>>>> This Feature-capability indicator indicates that the in= termediary >>>>>>> is a conference server, also known as a focus, and is c= apable of >>>>>>> mixing together the media for all calls to the same URI= . >>>>>>> ... >>>>>>> Examples of typical use: A conference bridge indicat= ing >>>>>>> that it >>>>>>> is a conference bridge and is capable of acting as a >>>>>>> conference >>>>>>> focus for this session. >>>>>>> >>>>>>> [AA] the presence of isfocus in a Feature-Caps header field means >>>>>>> that a UA can initiate a conference by sending a REFER request to >>>>>>> the intermediary to invite another user and create a multi user >>>>>>> conference from the 1-1 session. >>>>>>> >>>>>>> Note that Feature-Caps doesn't indicate which entity has this >>>>>>> capability, only that something does. And since this would >>>>>>> presumably only be used if it wasn't the UAC of the request, sendin= g >>>>>>> a subscribe to the contact address of the UAC wouldn't make sense. >>>>>>> >>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I conside= r >>>>>>> this application specific and so this would be included in a featur= e >>>>>>> tag registered in the global tree as stated in the draft "RFC 6809 >>>>>>> [1] provides that addresses of intermediaries can be communicated a= s >>>>>>> a value of an associated feature-capability indicator so it would b= e >>>>>>> appropriate to define feature capability indicators as part of the >>>>>>> global tree to communicate the GRUU of the intermediary and hence >>>>>>> this is outside the scope of this document." - RFC 6809 states " I= f >>>>>>> additional data about a supported feature needs to be conveyed, suc= h >>>>>>> as the address of the SIP entity that indicated support of the >>>>>>> feature, then the feature definition needs to define a way to conve= y >>>>>>> that information as a value of the associated feature-capability >>>>>>> indicator." However I think the SIP specific capability indicators >>>>>>> such as methods, extensions and events should appropriately be >>>>>>> registered in the SIP tree not as proprietary indicator >>>>>> s in the global tree. >>>>>> >>>>>> So you have defined a sip tree feature tag that is only useful in >>>>>> conjunction with another feature tag from the global tree. >>>>>> And the description of this feature tag doesn't even mention that. >>>>>> >>>>>> And this all implies a completely non-standard call model - doing >>>>>> conferencing in a way inconsistent with RFC 4579. >>>>>> >>>>>> ISTM that if 4579 doesn't work for you then you should be back >>>>>> proposing extensions/revisions to it. >>>>>> >>>>>>> If there is a conference bridge in the signaling path, then I would >>>>>>> expect it to be the UAC. >>>>>>> >>>>>>> [AA] Although a "standard" way to invoke a conference is to send a >>>>>>> REFER to the other UAs to invite them to the conference focus, in >>>>>>> many deployments a scenario exists where a call involves an IP-PBX >>>>>>> or Telephony Application Server (TAS) that can act as a focus for >>>>>>> the conference. A participant of a call can then create a conferenc= e >>>>>>> by sending a REFER request in dialog to the IP-PBX or TAS to use >>>>>>> 3PCC to Invite other users to a conference. Reasons for this are 1. >>>>>>> Not all UAs support REFER, >>>>>> >>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), but >>>>>> it *could become* a focus. >>>>>> >>>>>> The concept that a dialog may contain intermediaries that can be >>>>>> addressed to do stuff is not part of any sip standard that I am awar= e >>>>>> of. I don't care too much as long as the "stuff" is application stuf= f >>>>>> that is outside the scope of sip. But when it is alternative ways to >>>>>> do stuff that sip supports, then I get upset. >>>>>> >>>>>>> 2. Many SBCs reject REFER requests going outside domains because of >>>>>>> the potential for charging fraud (referring to a premium rate numbe= r >>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to join >>>>>>> the conference may be charged for initiating the call when the >>>>>>> scenario is that the initiator of the conference should be charged. >>>>>>> 4. No need to obtain and distribute conference URIs. >>>>>>> Problem is how to achieve the same behavior without dialog reuse >>>>>>> which has been deprecated by RFC 6665? >>>>>> >>>>>> Then maybe the problem needs to be brought up, and a standard >>>>>> solution proposed, rather than simply enabling a proprietary mechani= sm. >>>>>> >>>>>>> As another example, consider section 5.1: >>>>>>> >>>>>>> Descrition: >>>>>>> This Feature-capability indicator indicates that the in= termediary >>>>>>> supports audio as a streaming media type. >>>>>>> ... >>>>>>> Examples of typical use: An IP PBX indicating that i= t is >>>>>>> capable of accepting and initiating sessions with au= dio as a >>>>>>> streaming media type. >>>>>>> >>>>>>> This definition *implies* an assumption about the working >>>>>>> environment >>>>>>> - one that AFAIK is new. It implies that you need to know that >>>>>>> intermediaries support a media type before you can use it. Would it >>>>>>> be bad if there were no intermediaries, and so none indicated this? >>>>>>> What if some intermediary *did* indicate support, but some other >>>>>>> doesn't, but doesn't indicate that it doesn't? >>>>>>> >>>>>>> Bottom line: how would the presence or absence of this feature tag >>>>>>> affect subsequent usage? >>>>>>> >>>>>>> [AA] The absence of the streaming types does not indicate that the >>>>>>> intermediary does not support the media type and SDP offer answer >>>>>>> will ultimately determine what can or cannot be used if another >>>>>>> session is initiated involving the intermediary. However the >>>>>>> presence of the media type in a Feature-caps header field does >>>>>>> explictly confirm that the intermediary does support the media type >>>>>>> and in the scenario where a UA has a choice of multiple >>>>>>> intermediaries it could use for a conference it might choose to use >>>>>>> the one that explicitly indicates it supports the media types the U= A wants to use. >>>>>> >>>>>> So the UA will be able to discover that *some* intermediary supports >>>>>> media it is interested in. And it can tell that *some* intermediary >>>>>> says it is a focus. It doesn't know if they are the same intermediar= y. >>>>>> >>>>>> And then via some other feature tag it obtains the URI of *some* >>>>>> intermediary on the signaling path. Or maybe it gets more than one o= f >>>>>> these. >>>>>> >>>>>> It then makes a leap of faith and conflates all those things, to >>>>>> determine that the URI identifies a focus that supports this media t= ype. >>>>>> >>>>>> Even then, exactly what does that mean? It may or may not mean that >>>>>> it supports mixing that media type in a conference. >>>>>> >>>>>>> As I stated already I don't care that much about these streaming >>>>>>> media types. >>>>>> >>>>>>> I could go on, but this is enough for now. >>>>>>> >>>>>>> [AA] My motivation for this is that currently 3GPP are updating >>>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>>> >>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with >>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather than >>>>>>> forwarding it all the way to the remote UA. >>>>>> >>>>>> And 6665 deprecates dial reuse in most of those cases. >>>>>> Without dialog reuse, the intermediaries don't get an opportunity to >>>>>> intercept those. >>>>>> >>>>>>> In order to know that an intermediary supports the target dialog >>>>>>> mechanism needed for a REFER request sent outside the dialog to >>>>>>> work we need sip.extensions as a feature-capability indicator. In >>>>>>> order to know that the needed event package is supported by the >>>>>>> intermediary so we can SUBSCROBE outside the dialog to an >>>>>>> intermediary we need sip.events as a feature-capability indicator. >>>>>> >>>>>> Then I think you should be back here with a problem statement and a >>>>>> request for how to get sip to solve it. >>>>>> >>>>>> And you should touch base with Christer on this. He may have a >>>>>> different opinion on the relevance of feature-caps as a solution. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>>> >>>>>>>> I have submitted a new draft to sipcore to register a number of >>>>>>>> feature capability indicators in the SIP tree (based upon some of >>>>>>>> the existing SIP media feature tags). The draft can be found at: >>>>>>>> >>>>>>>>http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-= 00. >>>>>>>> txt >>>>>>>> >>>>>>>> Since there will not be a sipcore session at IETF#88 can we have >>>>>>>> an offline discussion on how to progress this draft (which >>>>>>>> hopefully is fairly straightforward as it just registers feature >>>>>>>> capabilities indicators with IANA). I wouldn't want to have to wai= t >>>>>>>> until March next year for a decision on progressing this. >>>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>>> ------------------------------------------------------------------= - >>>>>>>> - >>>>>>>> - This transmission (including any attachments) may contain >>>>>>>> confidential information, privileged material (including material >>>>>>>> protected by the solicitor-client or other applicable privileges), >>>>>>>> or constitute non-public information. Any use of this information >>>>>>>> by anyone other than the intended recipient is prohibited. If you >>>>>>>> have received this transmission in error, please immediately reply >>>>>>>> to the sender and delete this information from your system. Use, >>>>>>>> dissemination, distribution, or reproduction of this transmission >>>>>>>> by unintended recipients is not authorized and may be unlawful. >>>>>>> >>>>>>> -------------------------------------------------------------------= - >>>>>>> - This transmission (including any attachments) may contain >>>>>>> confidential information, privileged material (including material >>>>>>> protected by the solicitor-client or other applicable privileges), >>>>>>> or constitute non-public information. Any use of this information b= y >>>>>>> anyone other than the intended recipient is prohibited. If you have >>>>>>> received this transmission in error, please immediately reply to th= e >>>>>>> sender and delete this information from your system. Use, >>>>>>> dissemination, distribution, or reproduction of this transmission b= y >>>>>>> unintended recipients is not authorized and may be unlawful. >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> This transmission (including any attachments) may contain confidentia= l information, privileged material (including material protected by the sol= icitor-client or other applicable privileges), or constitute non-public inf= ormation. Any use of this information by anyone other than the intended re= cipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the soli= citor-client or other applicable privileges), or constitute non-public info= rmation. Any use of this information by anyone other than the intended rec= ipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the solic= itor-client or other applicable privileges), or constitute non-public infor= mation. Any use of this information by anyone other than the intended reci= pient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >>> >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential i= nformation, privileged material (including material protected by the solici= tor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recip= ient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and delete > this information from your system. Use, dissemination, distribution, or > reproduction of this transmission by unintended recipients is not > authorized and may be unlawful. > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and delete > this information from your system. Use, dissemination, distribution, or > reproduction of this transmission by unintended recipients is not > authorized and may be unlawful. > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B1C4F70FFESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

 

....

 

>> /Example:/ >>
>> I support the find-Paul feature, and I insert a FCI:
>>
>>      Feature-Caps: *, +g.find-paul=3D= "sip:pkyzivat@alum.mit.edu"
>>
>> Now, in this case the address does NOT point to my entity, but to = Paul's
>> entity. My entity supports a feature, which provides Paul's addres= s.
>>
>> So, if the FCI says:
>>
>>      Feature-Caps: *,
>> +g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.= methods=3D"invite"
>>
>> ...it doesn't automatically mean that I can contact Paul using INV= ITE.
>> By default it means that MY entity supports the INVITE method - wh= ich
>> from the find-paul feature perspective is useless information.
>>
>> So, in the FCI specification for +g.find-paul, I would have to=
>> explictily describe how the FCI works in conjunction with other FC= Is. I
>> would have to explicitly say that, when used together +sip.met= hods, the
>> +sip.methods indicates which SIP methods I can use to contact = Paul
>> (using the address provide in the +g.find-paul FCI).
>
> So far I agree.
>
> But suppose there is also a find-christer FCI. So we have:
>
> Feature-Caps: *
>    ;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu&= quot;
>    ;+g.find-paul=3D"sip:christer.holmberg@eric= sson.com"
>    ;+sip.methods=3D"invite"
>
> And both find-paul and find-christer want to define the use of other <= br> > FCIs. Then things start to become ambiguous.
>
> Should the description of find-paul specify what other FCIs "pert= ain" to
> it? Or should the description of sip.methods specify what FCI(s) provi= de
> the address at which it applies? Or both? What if paul and christer > support different methods?

 

In that case you would= need to have two different Feature-Caps header fields:

 

   &nbs= p;Feature-Caps: *;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu";= +sip.methods=3D"invite"
    Feature-Caps: *;+g.find-paul=3D"sip:christ= er.holmberg@ericsson.com";+sip.methods=3D"message"

 

In your example you ha= d two instances of the same FCI (is that even allowed?), but there could al= so have been a case with two different FCIs, both using +sip.methods, i= n which case you may have to put them into separate Feature-Caps header fields.

 

These things would hav= e to be clearly specified.

 

Regards,=

 

Christer=

 

 

 


> Section 5.3.8 in RFC 6809 also says:
>
>      "If there is additional information= about the feature-capability
>         indicator, it is recom= mended to describe such information.  It can
>         include, for example, = *names of related feature-capability
> indicators*."
>
> So, in your case, I think the +g.3gpp.see_trans FCI specifiction w= ould
> have to specify how the FCI is used in conjuntion with other FCIs,
> including the +sip.method FCI.
>
> Something like: "When the session transfer request is sent to the=
> address indicated by the FCI value, the +sip.method FCI indicates = which
> SIP methods can be used."
>
> Regards,
>
> Christer
>
>
>
> *From*: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> *Sent*: Friday, October 25, 2013 12:01 PM Central Standard Time
> *To*: Andrew Allen; Paul Kyzivat <pkyzivat@alum.mit.edu>; Gonzal= o
> Camarillo <gonzalo.camarillo@ericsson.com>
> *Cc*: rlb@ipv.sx <rlb@ipv.sx>; adam@nostrum.com <adam@nostrum= .com>;
> mary.ietf.barnes@gmail.com <mary.ietf.barnes@gmail.com>
> *Subject*: RE: New sipcore draft submission
> draft-allen-sipcore-sip-tree-cap-indicators
>
> Hi,
>
>>I think we can have an FCI
>
>>
>
>>Feature-Caps: *;+g.3ggp.sess_trans=3D=94sip:foo@example.com;gr= =94
>
>>
>
>>Indicating that the entity supports 3GPP session transfer and the a= ddress where you send the session transfer request is  sip:foo@example= .com;gr <mailto:= foo@example.com;gr>
>
> Correct. The FCI itself indicates support of session transfer feature,=
> and the FCI value indicates the address associatd with the feature. >
>>Also if I have:
>
>>
>
>>Feature-Caps: *;+g.3ggp.sess_trans=3Dsip:foo@example.com;gr; &#= 43;sip.extensions=3D=94replaces, tdialog=94;
> +sip.methods=3D=94invite, refer, bye, options, update, prack=94 >
>>
>
>> This means the entity supports 3GPP session transfer and the addre= ss where you send the session transfer request is  sip:foo@example.com= ;gr <mailto:foo@= example.com;gr>...
>
> Correct.
>
>> ...supports the replaces and target dialog extensions and supports= the following methods - invite, refer, bye, options, update, prack.
>
> Technically, what it means is that there is *AN* entity which supports=
> the features listed above, and the address is where you are to send th= e
> session transfer request in order to trigger the 3GPP session transfer=
> feature.
>
> Regards,
>
> Christer
>
> *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> *Sent:* Friday, October 25, 2013 10:25 AM
> *To:* Paul Kyzivat; Andrew Allen; Gonzalo Camarillo
> *Cc:* rlb@ipv.sx; adam@nostrum.com; mary.ietf.barnes@gmail.com
> *Subject:* RE: New sipcore draft submission
> draft-allen-sipcore-sip-tree-cap-indicators
>
> Hi,
>
> As Paul said, if one needs to provide address information associated > with a FCI, the address information cannot be a FCI of its own. It nee= ds
> to be a value of the FCI for which it is associated.
>
> Something like:
>
> Feature-Caps: *;+audio=3D"sip:foo@example.com"
>
> (Also note that the "+" sign is mandatory for all FCIs -= no matter which
> registry tree they belong to)
>
> Regards,
>
> Christer
>
> ----------------------------------------------------------------------= --
>
> *From:*Paul Kyzivat [pkyzivat@alum.mit.edu]
> *Sent:* Friday, 25 October 2013 5:06 PM
> *To:* Andrew Allen; Gonzalo Camarillo
> *Cc:* rlb@ipv.sx <m= ailto:rlb@ipv.sx>; adam@nostrum.com
> <mailto:adam@= nostrum.com>; Christer Holmberg; mary.ietf.barnes@gmail.com
> <ma= ilto:mary.ietf.barnes@gmail.com>
> *Subject:* Re: New sipcore draft submission
> draft-allen-sipcore-sip-tree-cap-indicators
>
> Andrew,
>
> (I see this is still on the private thread. I'll reply here, but this<= br> > exchange should probably be reposted to the sipcore list as part of th= e
> public discussion of the draft.)
>
> On 10/24/13 10:41 PM, Andrew Allen wrote:
>>
>> Paul
>>
>> I am happy to do a revision with more details on the semantics of = the capability indicators. However I don't think it should be held to a ver= y much higher bar than the details in RFC 3840 and the other media feature = tag RFCs regarding the meaning of those  tags.
>
> Keep in mind that the driving force for the definition of feature tags=
> in 3840 was in support of callerprefs (3841). So the context for the u= se
> of feature tags was that they would be placed on Contacts in REGISTER<= br> > requests. So you can interpret the definitions in that context: that a=
> request sent to an AOR using callerprefs can affect the choice of whic= h
> device the request goes to according to the capabilities it wants. In<= br> > that context audio, video, isfocus all make sense.
>
> Their use on Contacts in dialogs was derivative to that: because
> callerpref support is optional, there is no guarantee that the device<= br> > you reach via callerprefs will have the capabilities you requested. So=
> the values in the contact help confirm what you got.
>
> Of course they have since been used other ways. And the descriptions o= f
> them don't necessarily reflect that. IMO that is a defect due to the > evolution of use.
>
> I'm looking for the same sort of context for use with the feature-caps= .
>
> In private discussion you indicated to me that you expected the featur= e
> caps to be grouped - with one of them giving the URI of the device tha= t
> the other tags apply to. I guess this would end up looking something l= ike:
>
>     Feature-Caps: *;g.uri=3D"sip:foo@example.= com";audio
>     Feature-Caps: *;g.uri=3D"sip:bar@example.= com";audio;video;isfocus
>     Feature-Caps: *;g.uri=3D"sip:baz@example.= com";text
>
> (I'm making up g.uri for the example.)
>
> And then presumably somebody on the signaling path will "shop&quo= t; in the
> feature caps for the capabilities it wants, and then send a request to=
> that URI, with the expectation that the UA responding will have those<= br> > capabilities.
>
>> The semantics should be no different than those of  the corre= sponding existing media  feature tag if it is present in the Contact h= eader.
>
> Note that 6809 says:
>
>      When a SIP entity receives a SIP request= , or response, that contains
>      one or more Feature-Caps header fields, = the feature-capability
>      indicators in the header field inform th= e entity about the features
>      and capabilities supported by entities i= n the SIP message signaling
>      path.  The procedure by which featu= res and capabilities are invoked
>      are outside the scope of this specificat= ion and MUST be described by
>      individual feature-capability indicator = specifications.
>
>      A Feature-Caps header field value cannot= convey the address of the
>      SIP entity that inserted the Feature-Cap= s header field.  If
>      additional data about a supported featur= e needs to be conveyed, such
>      as the address of the SIP entity that in= dicated support of the
>      feature, then the feature definition nee= ds to define a way to convey
>      that information as a value of the assoc= iated feature-capability
>      indicator.
>
> This was discussed at length while that RFC was under consideration. Y= et
> the definitions of the tags in *this* draft don't specify that.
>
>> The registration templates currently reference the RFC 3840 and th= e other RFCs that define the other media feature tags that correspond to th= ese feature capability indicators.
>
> And those definitions were written to be understood in the context of<= br> > 3840/3841. They make sense in that context, but not in *this* context.=
>
>          Thanks,
>          Paul
>
>> But if more explicit detail is required then I can add some more t= ext  or alternatively remove the less important ones if they are going= to become rat holes. The ones I regard as really important and urgent are = sip.methods, sip.extensions and sip.events the  meaning of which I think should be quite clear.
>>
>> Andrew
>>
>> ----- Original Message -----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >> To: Andrew Allen;Gonzalo.Camarillo@ericsson.com <mailto:Gonzalo.Camari= llo@ericsson.com>
> <Gonzalo.Camarillo@ericsson.com <mailto:Gonzalo.Camarillo@ericsson.com<= /a>>>
>> Cc:rlb@ipv.sx <= mailto:rlb@ipv.sx> <rlb@ipv.sx <mailto:rlb@ipv.sx>>;
> adam@nostrum.com <mailto:adam@nostrum.com> <adam@nostrum.com
> <mailto:adam@= nostrum.com>>; christer.holmberg@ericsson.com
> <mailto:christer.holmberg@ericsson.com> <christer.holmberg@erics= son.com
> <mailto:christer.holmberg@ericsson.com>>; mary.ietf.barnes@gmail= .com
> <ma= ilto:mary.ietf.barnes@gmail.com> <mary.ietf.barnes@gmail.com
> <ma= ilto:mary.ietf.barnes@gmail.com>>; Paul Kyzivat
> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>>
>> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-= tree-cap-indicators
>>
>> On 10/24/13 4:07 PM, Andrew Allen wrote:
>>>
>>> Paul
>>>
>>> Ok
>>>
>>> So we are basically where I thought we were at when I submitte= d the draft.
>>>
>>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone= else who indicates interest) can have some offline discussion in Vancouver= on whether and how to progress this.
>>
>> As I indicated again on the sipcore list, I found the that the dra= ft
>> didn't explain nearly enough to allow meaningful use of these.
>> I know you replied, and I will continue the conversation there. >> But I will be opposed to these until and unless the draft (and not= ably
>> the descriptions of the tags) are clear about how one could figure= out
>> what can do in the presence of the tags that one couldn't do witho= ut
>> them. AND, that the behavior that suggests doesn't "break&quo= t; sip. (E.g.,
>> by advocating a new and incompatible way to do something.)
>>
>> We can continue this on the sipcore list.
>>
>>        Thanks,
>>        Paul
>>
>>> Andrew
>>>
>>> ----- Original Message -----
>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Tim= e
>>> To: Andrew Allen; Gonzalo Camarillo <Gonzalo.Camarillo@eric= sson.com <mailto:Gonzalo.Camarillo@ericsson.com>>
>>> Cc: Richard Barnes (rlb@ipv.sx <mailto:rlb@ipv.sx>) <rlb@ipv.sx <mailto:rlb@ipv.sx>>; Ada= m
> Roach (adam@nostrum.com <mailto:adam@nostrum.com>) <adam@nostrum.com
> <mailto:adam@= nostrum.com>>; Christer Holmberg
> (christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com= >)
> <christer.holmberg@ericsson.com
> <mailto:christer.holmberg@ericsson.com>>; Mary Barnes
> (mary.ietf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com>) < > mary.ietf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com>>
>>> Subject: Re: New sipcore draft submission draft-allen-sipcore-= sip-tree-cap-indicators
>>>
>>> On 10/24/13 2:17 PM, Andrew Allen wrote:
>>>> Paul
>>>>
>>>> That is fine. Although Mary in her reply to me seemed to i= ndicate maybe there was a possibility to use some of the DISPATCH spare tim= e for a SIPCORE session for this. Is that a possibility?
>>>>
>>>> I already replied to your post
>>>
>>> I discussed that with Adam. We decided we can't set a preceden= t to spin
>>> up a session to discuss a draft that hasn't had substantial (a= ny) list
>>> discussion.
>>>
>>> But list discussion is always welcome.
>>>
>>>       Sorry,
>>>       Paul
>>>
>>>> Andrew
>>>>
>>>> -----Original Message-----
>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>> Sent: Thursday, October 24, 2013 1:31 PM
>>>> To: Andrew Allen; Gonzalo Camarillo
>>>> Cc: Richard Barnes (rlb@ipv.sx <mailto:rlb@ipv.sx>); Adam Roach (adam@nostr= um.com
> <mailto:adam@= nostrum.com>); Christer Holmberg
> (christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com= >)
>>>> Subject: Re: New sipcore draft submission draft-allen-sipc= ore-sip-tree-cap-indicators
>>>>
>>>> Andrew,
>>>>
>>>> I spoke with Mary about it, and we concluded that dispatch= isn't right for this. (In addition to being clearly sipcore, it didn't mee= t the deadline for dispatch.) I was wrong to encourage you that way.
>>>>
>>>> So no official live discussion in Vancouver. (But informal= discussion
>>>> fine.)
>>>>
>>>> I'll resend my private comments to the sipcore list to kic= kstart some discussion there.
>>>>
>>>>      Thanks,
>>>>      Paul
>>>>
>>>> On 10/24/13 1:01 PM, Andrew Allen wrote:
>>>>> I just emailed Mary asking for agenda time. Should I c= ancel that request?
>>>>>
>>>>> -----Original Message-----
>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.co= m]
>>>>> Sent: Thursday, October 24, 2013 1:00 PM
>>>>> To: Paul Kyzivat
>>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx <mailto:rlb@ipv.sx>); Adam= Roach
>>>>> (adam@nostrum.com <mailto:adam@nostrum.com>); Christer Holmberg > (christer.holmberg@ericsson.com <mailto:christer.holmberg@ericsson.com= >)
>>>>> Subject: Re: New sipcore draft submission
>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>
>>>>> Hi Paul,
>>>>>
>>>>> given that you think this belongs to SIPCORE, I do not= see the need to run it through DISPATCH. Please, start technical discussio= ns on the draft on the SIPCORE list.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Gonzalo
>>>>>
>>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote:
>>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote:
>>>>>>> Paul
>>>>>>>
>>>>>>> Thanks for reviewing the draft already and giv= ing me early feedback.
>>>>>>>
>>>>>>> My responses below inline (prepended with [AA)= .
>>>>>>>
>>>>>>> Can I ask the ADs to determine ASAP if this ne= eds to go to DISPATCH
>>>>>>> first or not. As outlined below my view is tha= t it is unnecessary
>>>>>>> for every little thing to go to DISPATCH as th= is just creates
>>>>>>> additional delay and overhead. If it is to be = discussed in DISPATCH
>>>>>>> then I definitely would want agenda time atIET= F#88 for this.
>>>>>>
>>>>>> Having now seen Andrew's responses to my initial q= uestions, I think
>>>>>> this
>>>>>> *needs* to be carefully considered by sipcore. IMO= this has the
>>>>>> potential to create a dialect of sip that is incom= patible with normal
>>>>>> usage. (Maybe IMS has already done that. But this = will make it
>>>>>> worse.)
>>>>>>
>>>>>> But if there is a desire to discuss it publicly in= Vancouver then
>>>>>> dispatch is the opportunity and so some discussion= on the dispatch
>>>>>> list in advance of that would be appropriate.
>>>>>>
>>>>>> I'll defer to the ADs on this.
>>>>>>
>>>>>> More inline.
>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM
>>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx &= lt;mailto:rlb@ipv.sx>= ;); Gonzalo Camarillo
>>>>>>> (Gonzalo.Camarillo@ericsson.com <mailto:Gonzalo.Ca= marillo@ericsson.com>);
> Adam Roach (adam@nostrum.com <mailto:adam@nostrum.com>)
>>>>>>> Subject: Re: New sipcore draft submission
>>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>>
>>>>>>> Andrew,
>>>>>>>
>>>>>>> On a legalistic note, its questionable to me w= hether this kind of
>>>>>>> action falls within the scope of sipcore. OTOH= , among existing wgs,
>>>>>>> sipcore is probably the best suited to discuss= the proposal. We
>>>>>>> could take it to DISPATCH. I think DISPATCH ha= s extra time in its
>>>>>>> agenda for Vancouver, so that might be one opt= ion for you. But then
>>>>>>> I don't know where dispatch would dispatch it.= It may be that AD
>>>>>>> sponsored is the best way to go.
>>>>>>>
>>>>>>> [AA] It seemed to me that sipcore was the righ= t place. This draft
>>>>>>> registers feature-capability indicators in a r= egistry that was
>>>>>>> created by a sipcore RFC (RFC 6809). You could= in my view make an
>>>>>>> argument that this should even have been done = as part of RFC 6809.
>>>>>>
>>>>>> If this was just a matter of registering some new = feature caps that
>>>>>> were not controversial, then I don't think sipcore= needs to be involved.
>>>>>>
>>>>>> But as I mentioned above, I do consider these cont= roversial.
>>>>>>
>>>>>>> Discussing it now on the dispatch list would b= e a good start toward
>>>>>>> discussing it at the dispatch session.
>>>>>>>
>>>>>>> [AA] Can I ask the ADs to determine if this ne= eds to go to DISPATCH
>>>>>>> first or not. My view is that it is unnecessar= y for every little
>>>>>>> thing to go to DISPATCH as this just creates a= dditional delay and overhead.
>>>>>>> This just registers some indicators in an exis= ting IANA registry and
>>>>>>> is not (or should not be IMHO) a major project= .
>>>>>>
>>>>>> To me this is a matter of whether you want to be o= pportunistic.
>>>>>> If this went to dispatch I would now recommend tha= t it be dispatched
>>>>>> to sipcore. So its a matter of whether you want to= talk about it in
>>>>>> the dispatch meeting.
>>>>>>
>>>>>>> Regarding substance, this draft troubles me. I= t takes feature-caps
>>>>>>> in exactly the direction that I found most con= cerning about the
>>>>>>> mechanism in the first place.
>>>>>>>
>>>>>>> Your draft partitions the existing media featu= re tags into two sets
>>>>>>> - those that would be useful as feature-capabi= lity-indicators, and
>>>>>>> those that aren't. But I see no explanation of= the criteria used to
>>>>>>> make this distinction, nor can I think of one.=
>>>>>>>
>>>>>>> [AA] I based this decision on the following cr= iteria: If a feature
>>>>>>> tag was potentially at all useful for an inter= mediary to indicate it
>>>>>>> then include it in the registry. The ones not = included are either
>>>>>>> directly associated with the user (intermediar= ies are not  directly
>>>>>>> associated with the user) or would only ever h= ave one value (e.g
>>>>>>> automata).  I am not sure that every feat= ure-capability indicator
>>>>>>> proposed to be registered is actually useful b= ut then I don't think
>>>>>>> every media feature tag registered by RFC 3840= is either (I doubt
>>>>>>> very much if there are implementation using th= e sip.application or
>>>>>>> sip.control feature tags). I don't think RFC 3= 840 goes into a lot of
>>>>>>> details justifying of ever registered media fe= ature tag and
>>>>>>> specifying the details of how they would be us= ed either.  I am
>>>>>>> willing to remove any feature-capability indic= ators that are
>>>>>>> controversial except that I think we definitel= y need sip.extensions, sip.methods and sip.events.
>>>>>>> There is a significant overhead to writing an<= br> >>>>>> d progressing internet drafts so my view is lets r= egister all that
>>>>>> might be remotely useful in the same document.
>>>>>>
>>>>>> The judgement of "useful" is reasonable.= But I still can't discern
>>>>>> what the use is from the iana registration descrip= tions.
>>>>>>
>>>>>>> For the ones that you have requested feature c= apability indicators,
>>>>>>> I cannot figure out what using them would mean= . For example, when I
>>>>>>> see isFocus on a Contact header I know I am in= a conference, and
>>>>>>> that I can subscribe to the conference event p= ackage at the contact
>>>>>>> URI. If I see isFocus in a Feature-Caps header= , what does it mean?
>>>>>>> What can I do once I know this?
>>>>>>>
>>>>>>> Section 5.14 of this draft says:
>>>>>>>
>>>>>>>        = ;     This Feature-capability indicator indicates that = the intermediary
>>>>>>>        = ;     is a conference server, also known as a focus, an= d is capable of
>>>>>>>        = ;     mixing together the media for all calls to the sa= me URI.
>>>>>>> ...
>>>>>>>        = ;        Examples of typical use: A conf= erence bridge indicating
>>>>>>> that it
>>>>>>>        = ;        is a conference bridge and is c= apable of acting as a
>>>>>>> conference
>>>>>>>        = ;        focus for this session.
>>>>>>>
>>>>>>> [AA] the presence of isfocus in a Feature-Caps= header field means
>>>>>>> that a UA can initiate a conference by sending= a REFER request to
>>>>>>> the intermediary to invite another user and cr= eate a multi user
>>>>>>> conference from the 1-1 session.
>>>>>>>
>>>>>>> Note that Feature-Caps doesn't indicate which = entity has this
>>>>>>> capability, only that something does. And sinc= e this would
>>>>>>> presumably only be used if it wasn't the UAC o= f the request, sending
>>>>>>> a subscribe to the contact address of the UAC = wouldn't make sense.
>>>>>>>
>>>>>>> [AA] Yes the GRUU of the intermediary would be= needed but I consider
>>>>>>> this application specific and so this would be= included in a feature
>>>>>>> tag registered in the global tree as stated in= the draft "RFC 6809
>>>>>>> [1] provides that addresses of intermediaries = can be communicated as
>>>>>>> a value of an associated feature-capability in= dicator so it would be
>>>>>>> appropriate to define feature capability indic= ators as part of the
>>>>>>> global tree to communicate the GRUU of the int= ermediary and hence
>>>>>>> this is outside the scope of this document.&qu= ot;  - RFC 6809 states " If
>>>>>>> additional data about a supported feature need= s to be conveyed, such
>>>>>>> as the address of the SIP entity that indicate= d support of the
>>>>>>> feature, then the feature definition needs to = define a way to convey
>>>>>>> that information as a value of the associated = feature-capability
>>>>>>> indicator." However I think the SIP speci= fic capability indicators
>>>>>>> such as methods, extensions and events should = appropriately be
>>>>>>> registered in the SIP tree not as proprietary = indicator
>>>>>> s in the global tree.
>>>>>>
>>>>>> So you have defined a sip tree feature tag that is= only useful in
>>>>>> conjunction with another feature tag from the glob= al tree.
>>>>>> And the description of this feature tag doesn't ev= en mention that.
>>>>>>
>>>>>> And this all implies a completely non-standard cal= l model - doing
>>>>>> conferencing in a way inconsistent with RFC 4579.<= br> >>>>>>
>>>>>> ISTM that if 4579 doesn't work for you then you sh= ould be back
>>>>>> proposing extensions/revisions to it.
>>>>>>
>>>>>>> If there is a conference bridge in the signali= ng path, then I would
>>>>>>> expect it to be the UAC.
>>>>>>>
>>>>>>> [AA] Although a "standard" way to in= voke a conference is to send a
>>>>>>> REFER to the other UAs to invite them to the c= onference focus,  in
>>>>>>> many deployments a scenario exists where a cal= l involves an IP-PBX
>>>>>>> or Telephony Application Server (TAS) that can= act as a focus for
>>>>>>> the conference. A participant of a call can th= en create a conference
>>>>>>> by sending a REFER request in dialog to the IP= -PBX or TAS to use
>>>>>>> 3PCC to Invite other users to a conference. Re= asons for this are 1.
>>>>>>> Not all UAs support REFER,
>>>>>>
>>>>>> So you are saying the intermediary isn't a focus (= its a B2BUA), but
>>>>>> it *could become* a focus.
>>>>>>
>>>>>> The concept that a dialog may contain intermediari= es that can be
>>>>>> addressed to do stuff is not part of any sip stand= ard that I am aware
>>>>>> of. I don't care too much as long as the "stu= ff" is application stuff
>>>>>> that is outside the scope of sip. But when it is a= lternative ways to
>>>>>> do stuff that sip supports, then I get upset.
>>>>>>
>>>>>>> 2. Many SBCs reject REFER requests going outsi= de domains because of
>>>>>>> the potential for charging fraud (referring to= a premium rate number
>>>>>>> etc) 3. A User receiving a REFER and then usin= g an INVITE to join
>>>>>>> the conference may be charged for initiating&n= bsp; the call when the
>>>>>>> scenario is that the initiator of the conferen= ce should be charged.
>>>>>>> 4. No need to obtain and distribute conference= URIs.
>>>>>>> Problem is how to achieve the same behavior wi= thout dialog reuse
>>>>>>> which has been deprecated by RFC 6665?
>>>>>>
>>>>>> Then maybe the problem needs to be brought up, and= a standard
>>>>>> solution proposed, rather than simply enabling a p= roprietary mechanism.
>>>>>>
>>>>>>> As another example, consider section 5.1:
>>>>>>>
>>>>>>>        = ;     Descrition:
>>>>>>>        = ;     This Feature-capability indicator indicates that = the intermediary
>>>>>>>        = ;     supports audio as a streaming media type.
>>>>>>> ...
>>>>>>>        = ;        Examples of typical use: An IP = PBX indicating that it is
>>>>>>>        = ;        capable of accepting and initia= ting sessions with audio as a
>>>>>>>        = ;        streaming media type.
>>>>>>>
>>>>>>> This definition *implies* an assumption about = the working
>>>>>>> environment
>>>>>>> - one that AFAIK is new. It implies that you n= eed to know that
>>>>>>> intermediaries support a media type before you= can use it. Would it
>>>>>>> be bad if there were no intermediaries, and so= none indicated this?
>>>>>>> What if some intermediary *did* indicate suppo= rt, but some other
>>>>>>> doesn't, but doesn't indicate that it doesn't?=
>>>>>>>
>>>>>>> Bottom line: how would the presence or absence= of this feature tag
>>>>>>> affect subsequent usage?
>>>>>>>
>>>>>>> [AA] The absence of the streaming types does n= ot indicate that the
>>>>>>> intermediary does not support the media type a= nd SDP offer answer
>>>>>>> will ultimately determine what can or cannot b= e used if another
>>>>>>> session is initiated involving the intermediar= y. However the
>>>>>>> presence of the media type in a Feature-caps h= eader field does
>>>>>>> explictly confirm that the intermediary does s= upport the media type
>>>>>>> and in the scenario where a UA has a choice of= multiple
>>>>>>> intermediaries it could use for a conference i= t might choose to use
>>>>>>> the one that explicitly indicates it supports = the media types the UA wants to use.
>>>>>>
>>>>>> So the UA will be able to discover that *some* int= ermediary supports
>>>>>> media it is interested in. And it can tell that *s= ome* intermediary
>>>>>> says it is a focus. It doesn't know if they are th= e same intermediary.
>>>>>>
>>>>>> And then via some other feature tag it obtains the= URI of *some*
>>>>>> intermediary on the signaling path. Or maybe it ge= ts more than one of
>>>>>> these.
>>>>>>
>>>>>> It then makes a leap of faith and conflates all th= ose things, to
>>>>>> determine that the URI identifies a focus that sup= ports this media type.
>>>>>>
>>>>>> Even then, exactly what does that mean? It may or = may not mean that
>>>>>> it supports mixing that media type in a conference= .
>>>>>>
>>>>>>> As I stated already I don't care that much abo= ut these streaming
>>>>>>> media types.
>>>>>>
>>>>>>> I could go on, but this is enough for now.
>>>>>>>
>>>>>>> [AA] My motivation for this is that currently = 3GPP are updating
>>>>>>> their specifications to use RFC 6665 instead o= f RFC 3265.
>>>>>>
>>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE = and REFER with
>>>>>>> intermediaries accepting the REFER or SUBSCRIB= E request rather than
>>>>>>> forwarding it all the way to the remote UA. >>>>>>
>>>>>> And 6665 deprecates dial reuse in most of those ca= ses.
>>>>>> Without dialog reuse, the intermediaries don't get= an opportunity to
>>>>>> intercept those.
>>>>>>
>>>>>>> In order to know that an intermediary supports= the target dialog
>>>>>>> mechanism  needed for a REFER request sen= t outside the dialog to
>>>>>>> work we need sip.extensions as a feature-capab= ility indicator. In
>>>>>>> order to know that the needed event package is= supported by the
>>>>>>> intermediary so we can SUBSCROBE outside the d= ialog to an
>>>>>>> intermediary we need sip.events as a feature-c= apability indicator.
>>>>>>
>>>>>> Then I think you should be back here with a proble= m statement and a
>>>>>> request for how to get sip to solve it.
>>>>>>
>>>>>> And you should touch base with Christer on this. H= e may have a
>>>>>> different opinion on the relevance of feature-caps= as a solution.
>>>>>>
>>>>>>         Th= anks,
>>>>>>         Pa= ul
>>>>>>
>>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote:
>>>>>>>> Adam, Paul, Richard, Gonzalo
>>>>>>>>
>>>>>>>> I have submitted a new draft to sipcore&nb= sp; to register a number of
>>>>>>>> feature capability indicators in the SIP t= ree (based upon some of
>>>>>>>> the existing SIP media feature tags). The = draft can be found at:
>>>>>>>>
>>>>>>>>http://www.ietf.or= g/id/draft-allen-sipcore-sip-tree-cap-indicators-00.
>>>>>>>> txt
>>>>>>>>
>>>>>>>> Since there will not be a sipcore session = at IETF#88  can we have
>>>>>>>> an offline discussion on how to progress t= his draft (which
>>>>>>>> hopefully is fairly straightforward as it = just registers feature
>>>>>>>> capabilities indicators with IANA). I woul= dn't want to have to wait
>>>>>>>> until March next year for a decision on pr= ogressing this.
>>>>>>>>
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>> ------------------------------------------= -------------------------
>>>>>>>> -
>>>>>>>> - This transmission (including any attachm= ents) may contain
>>>>>>>> confidential information, privileged mater= ial (including material
>>>>>>>> protected by the solicitor-client or other= applicable privileges),
>>>>>>>> or constitute non-public information. Any = use of this information
>>>>>>>> by anyone other than the intended recipien= t is prohibited. If you
>>>>>>>> have received this transmission in error, = please immediately reply
>>>>>>>> to the sender and delete this information = from your system. Use,
>>>>>>>> dissemination, distribution, or reproducti= on of this transmission
>>>>>>>> by unintended recipients is not authorized= and may be unlawful.
>>>>>>>
>>>>>>> ----------------------------------------------= ----------------------
>>>>>>> - This transmission (including any attachments= ) may contain
>>>>>>> confidential information, privileged material = (including material
>>>>>>> protected by the solicitor-client or other app= licable privileges),
>>>>>>> or constitute non-public information. Any use = of this information by
>>>>>>> anyone other than the intended recipient is pr= ohibited. If you have
>>>>>>> received this transmission in error, please im= mediately reply to the
>>>>>>> sender and delete this information from your s= ystem. Use,
>>>>>>> dissemination, distribution, or reproduction o= f this transmission by
>>>>>>> unintended recipients is not authorized and ma= y be unlawful.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------= ---------------
>>>>> This transmission (including any attachments) may cont= ain confidential information, privileged material (including material prote= cted by the solicitor-client or other applicable privileges), or constitute= non-public information. Any use of this information  by anyone other than the intended recipient is prohibited. If you have
> received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, disseminatio= n,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.
>>>>>
>>>>>
>>>>
>>>> ----------------------------------------------------------= -----------
>>>> This transmission (including any attachments) may contain = confidential information, privileged material (including material protected= by the solicitor-client or other applicable privileges), or constitute non= -public information. Any use of this information  by anyone other than the intended recipient is prohibited. If you have
> received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, disseminatio= n,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.
>>>>
>>>>
>>>
>>> --------------------------------------------------------------= -------
>>> This transmission (including any attachments) may contain conf= idential information, privileged material (including material protected by = the solicitor-client or other applicable privileges), or constitute non-pub= lic information. Any use of this information  by anyone other than the intended recipient is prohibited. If you have
> received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, disseminatio= n,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.
>>>
>>>
>>
>> ------------------------------------------------------------------= ---
>> This transmission (including any attachments) may contain confiden= tial information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute non-public = information. Any use of this information  by anyone other than the intended recipient is prohibited. If you have
> received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, disseminatio= n,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.
>>
>>
>
> ---------------------------------------------------------------------<= br> > This transmission (including any attachments) may contain confidential=
> information, privileged material (including material protected by the<= br> > solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other th= an
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and dele= te
> this information from your system. Use, dissemination, distribution, o= r
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> ---------------------------------------------------------------------<= br> > This transmission (including any attachments) may contain confidential=
> information, privileged material (including material protected by the<= br> > solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other th= an
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and dele= te
> this information from your system. Use, dissemination, distribution, o= r
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--_000_7594FB04B1934943A5C02806D1A2204B1C4F70FFESESSMB209erics_-- From aallen@blackberry.com Fri Oct 25 12:00:47 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D0D11E8176 for ; Fri, 25 Oct 2013 12:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.133 X-Spam-Level: X-Spam-Status: No, score=-1.133 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMGGjwuEUgaV for ; Fri, 25 Oct 2013 12:00:41 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 5250211E8201 for ; Fri, 25 Oct 2013 12:00:22 -0700 (PDT) Received: from xct105ads.rim.net ([10.67.111.46]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 25 Oct 2013 15:00:17 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.03.0123.003; Fri, 25 Oct 2013 14:00:16 -0500 From: Andrew Allen To: Christer Holmberg , Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0bKxmuu2OBPqMUmxvta8f/E6B5oFxJ0g Date: Fri, 25 Oct 2013 19:00:15 +0000 Message-ID: References: <526A7ADF.8010106@alum.mit.edu> , <526ABAAC.1000304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70BF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4F70BF@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338E3CD3AXMB104ADSrimnet_" MIME-Version: 1.0 Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:00:48 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338E3CD3AXMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable If the semantic of g.x is defined as the support for the session transfer c= apability and the URI at the entity including it for sending request to inv= oke the session transfer then the sip methods and sip extensions also incl= uded in the Feature-Caps header field also apply to the URI for session tra= nsfer. Andrew From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, October 25, 2013 2:47 PM To: Paul Kyzivat; Andrew Allen; SIPCORE Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators Hi, >> The next revisions will contain more details on what each FCI (as Christ= er now calls them means). >> >> If some are not well understood I will remove them from the draft (i.e. = drop the rat holes) >> >> I think my email exchange with Christer clarifies the other points. >> >> Does this represent in principle a way forward? > > Maybe. We'll have to see how it goes. > > The challenge is, I think, that you want to bring in a bunch of the 3840 > feature tags, and have them mean something akin to what they do as > feature tags when used as FCIs. But there needs to be some way to > describe what *each* one means. It's not immediately clear to me how to > do that. As I said in another reply, I think that the FCIs that use the +sip.method = etc FCIs need to describe how they are used in conjunction. Example: Feature-Caps: *;+g.x;+sip.methods=3D"INVITE" Feature-Caps: *;+g.y;+sip.methods=3D"INVITE" The FCI specifications for +g.x and +g.y need to describe how they are used= together with +sip.methods, if there is a relationship. Otherwise +sip.methods only means that the entity that inserted the FCIs su= pport "INVITE". Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, October 25, 2013 10:06 AM > To: Andrew Allen; Gonzalo.Camarillo@ericsson.com > Cc: rlb@ipv.sx; adam@nostrum.com; christer.holmberg@ericsson.com;= mary.ietf.barnes@gmail.com > Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-ca= p-indicators > > Andrew, > > (I see this is still on the private thread. I'll reply here, but this exc= hange should probably be reposted to the sipcore list as part of the public= discussion of the draft.) > > On 10/24/13 10:41 PM, Andrew Allen wrote: >> >> Paul >> >> I am happy to do a revision with more details on the semantics of the ca= pability indicators. However I don't think it should be held to a very much= higher bar than the details in RFC 3840 and the other media feature tag RF= Cs regarding the meaning of those tags. > > Keep in mind that the driving force for the definition of feature tags in= 3840 was in support of callerprefs (3841). So the context for the use of f= eature tags was that they would be placed on Contacts in REGISTER requests.= So you can interpret the definitions in that context: that a request sent = to an AOR using callerprefs can affect the choice of which device the reque= st goes to according to the capabilities it wants. In that context audio, v= ideo, isfocus all make sense. > > Their use on Contacts in dialogs was derivative to that: because callerpr= ef support is optional, there is no guarantee that the device you reach via= callerprefs will have the capabilities you requested. So the values in the= contact help confirm what you got. > > Of course they have since been used other ways. And the descriptions of t= hem don't necessarily reflect that. IMO that is a defect due to the evoluti= on of use. > > I'm looking for the same sort of context for use with the feature-caps. > > In private discussion you indicated to me that you expected the feature c= aps to be grouped - with one of them giving the URI of the device that the = other tags apply to. I guess this would end up looking something like: > > Feature-Caps: *;g.uri=3D"sip:foo@example.com";audio > Feature-Caps: *;g.uri=3D"sip:bar@example.com";audio;video;isfocus > Feature-Caps: *;g.uri=3D"sip:baz@example.com";text > > (I'm making up g.uri for the example.) > > And then presumably somebody on the signaling path will "shop" in the fea= ture caps for the capabilities it wants, and then send a request to that UR= I, with the expectation that the UA responding will have those capabilities. > >> The semantics should be no different than those of the corresponding ex= isting media feature tag if it is present in the Contact header. > > Note that 6809 says: > > When a SIP entity receives a SIP request, or response, that contains > one or more Feature-Caps header fields, the feature-capability > indicators in the header field inform the entity about the features > and capabilities supported by entities in the SIP message signaling > path. The procedure by which features and capabilities are invoked > are outside the scope of this specification and MUST be described by > individual feature-capability indicator specifications. > > A Feature-Caps header field value cannot convey the address of the > SIP entity that inserted the Feature-Caps header field. If > additional data about a supported feature needs to be conveyed, such > as the address of the SIP entity that indicated support of the > feature, then the feature definition needs to define a way to convey > that information as a value of the associated feature-capability > indicator. > > This was discussed at length while that RFC was under consideration. Yet = the definitions of the tags in *this* draft don't specify that. > >> The registration templates currently reference the RFC 3840 and the othe= r RFCs that define the other media feature tags that correspond to these fe= ature capability indicators. > > And those definitions were written to be understood in the context of 384= 0/3841. They make sense in that context, but not in *this* context. > > Thanks, > Paul > >> But if more explicit detail is required then I can add some more text o= r alternatively remove the less important ones if they are going to become = rat holes. The ones I regard as really important and urgent are sip.methods= , sip.extensions and sip.events the meaning of which I think should be quit= e clear. >> >> Andrew >> >> ----- Original Message ----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com >> > >> Cc: rlb@ipv.sx >; adam@= nostrum.com >; >> christer.holmberg@ericsson.com >; >> mary.ietf.barnes@gmail.com >; Paul Kyzivat >> > >> Subject: Re: New sipcore draft submission >> draft-allen-sipcore-sip-tree-cap-indicators >> >> On 10/24/13 4:07 PM, Andrew Allen wrote: >>> >>> Paul >>> >>> Ok >>> >>> So we are basically where I thought we were at when I submitted the dra= ft. >>> >>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who= indicates interest) can have some offline discussion in Vancouver on wheth= er and how to progress this. >> >> As I indicated again on the sipcore list, I found the that the draft >> didn't explain nearly enough to allow meaningful use of these. >> I know you replied, and I will continue the conversation there. >> But I will be opposed to these until and unless the draft (and notably >> the descriptions of the tags) are clear about how one could figure out >> what can do in the presence of the tags that one couldn't do without >> them. AND, that the behavior that suggests doesn't "break" sip. (E.g., >> by advocating a new and incompatible way to do something.) >> >> We can continue this on the sipcore list. >> >> Thanks, >> Paul >> >>> Andrew >>> >>> ----- Original Message ----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >>> To: Andrew Allen; Gonzalo Camarillo > >>> Cc: Richard Barnes (rlb@ipv.sx) >; Adam Roach >>> (adam@nostrum.com) >; Christer Holmberg >>> (christer.holmberg@ericsson.com)= >; >>> Mary Barnes (mary.ietf.barnes@gmail.com) > >>> Subject: Re: New sipcore draft submission >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> On 10/24/13 2:17 PM, Andrew Allen wrote: >>>> Paul >>>> >>>> That is fine. Although Mary in her reply to me seemed to indicate mayb= e there was a possibility to use some of the DISPATCH spare time for a SIPC= ORE session for this. Is that a possibility? >>>> >>>> I already replied to your post >>> >>> I discussed that with Adam. We decided we can't set a precedent to >>> spin up a session to discuss a draft that hasn't had substantial >>> (any) list discussion. >>> >>> But list discussion is always welcome. >>> >>> Sorry, >>> Paul >>> >>>> Andrew >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, October 24, 2013 1:31 PM >>>> To: Andrew Allen; Gonzalo Camarillo >>>> Cc: Richard Barnes (rlb@ipv.sx); Adam Roach (adam@n= ostrum.com); >>>> Christer Holmberg (christer.holmberg@ericsson.com) >>>> Subject: Re: New sipcore draft submission >>>> draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> Andrew, >>>> >>>> I spoke with Mary about it, and we concluded that dispatch isn't right= for this. (In addition to being clearly sipcore, it didn't meet the deadli= ne for dispatch.) I was wrong to encourage you that way. >>>> >>>> So no official live discussion in Vancouver. (But informal >>>> discussion >>>> fine.) >>>> >>>> I'll resend my private comments to the sipcore list to kickstart some = discussion there. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>>> I just emailed Mary asking for agenda time. Should I cancel that requ= est? >>>>> >>>>> -----Original Message----- >>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>> Sent: Thursday, October 24, 2013 1:00 PM >>>>> To: Paul Kyzivat >>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx); Ada= m Roach >>>>> (adam@nostrum.com); Christer Holmberg >>>>> (christer.holmberg@ericsson.com) >>>>> Subject: Re: New sipcore draft submission >>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>> >>>>> Hi Paul, >>>>> >>>>> given that you think this belongs to SIPCORE, I do not see the need t= o run it through DISPATCH. Please, start technical discussions on the draft= on the SIPCORE list. >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>>> Paul >>>>>>> >>>>>>> Thanks for reviewing the draft already and giving me early feedback. >>>>>>> >>>>>>> My responses below inline (prepended with [AA). >>>>>>> >>>>>>> Can I ask the ADs to determine ASAP if this needs to go to >>>>>>> DISPATCH first or not. As outlined below my view is that it is >>>>>>> unnecessary for every little thing to go to DISPATCH as this just >>>>>>> creates additional delay and overhead. If it is to be discussed >>>>>>> in DISPATCH then I definitely would want agenda time atIETF#88 for = this. >>>>>> >>>>>> Having now seen Andrew's responses to my initial questions, I >>>>>> think this >>>>>> *needs* to be carefully considered by sipcore. IMO this has the >>>>>> potential to create a dialect of sip that is incompatible with >>>>>> normal usage. (Maybe IMS has already done that. But this will make >>>>>> it >>>>>> worse.) >>>>>> >>>>>> But if there is a desire to discuss it publicly in Vancouver then >>>>>> dispatch is the opportunity and so some discussion on the dispatch >>>>>> list in advance of that would be appropriate. >>>>>> >>>>>> I'll defer to the ADs on this. >>>>>> >>>>>> More inline. >>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx); G= onzalo Camarillo >>>>>>> (Gonzalo.Camarillo@ericsson.com); Adam Roach (adam@nostrum.com) >>>>>>> Subject: Re: New sipcore draft submission >>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>> >>>>>>> Andrew, >>>>>>> >>>>>>> On a legalistic note, its questionable to me whether this kind of >>>>>>> action falls within the scope of sipcore. OTOH, among existing >>>>>>> wgs, sipcore is probably the best suited to discuss the proposal. >>>>>>> We could take it to DISPATCH. I think DISPATCH has extra time in >>>>>>> its agenda for Vancouver, so that might be one option for you. >>>>>>> But then I don't know where dispatch would dispatch it. It may be >>>>>>> that AD sponsored is the best way to go. >>>>>>> >>>>>>> [AA] It seemed to me that sipcore was the right place. This draft >>>>>>> registers feature-capability indicators in a registry that was >>>>>>> created by a sipcore RFC (RFC 6809). You could in my view make an >>>>>>> argument that this should even have been done as part of RFC 6809. >>>>>> >>>>>> If this was just a matter of registering some new feature caps >>>>>> that were not controversial, then I don't think sipcore needs to be = involved. >>>>>> >>>>>> But as I mentioned above, I do consider these controversial. >>>>>> >>>>>>> Discussing it now on the dispatch list would be a good start >>>>>>> toward discussing it at the dispatch session. >>>>>>> >>>>>>> [AA] Can I ask the ADs to determine if this needs to go to >>>>>>> DISPATCH first or not. My view is that it is unnecessary for >>>>>>> every little thing to go to DISPATCH as this just creates additiona= l delay and overhead. >>>>>>> This just registers some indicators in an existing IANA registry >>>>>>> and is not (or should not be IMHO) a major project. >>>>>> >>>>>> To me this is a matter of whether you want to be opportunistic. >>>>>> If this went to dispatch I would now recommend that it be >>>>>> dispatched to sipcore. So its a matter of whether you want to talk >>>>>> about it in the dispatch meeting. >>>>>> >>>>>>> Regarding substance, this draft troubles me. It takes >>>>>>> feature-caps in exactly the direction that I found most >>>>>>> concerning about the mechanism in the first place. >>>>>>> >>>>>>> Your draft partitions the existing media feature tags into two >>>>>>> sets >>>>>>> - those that would be useful as feature-capability-indicators, >>>>>>> and those that aren't. But I see no explanation of the criteria >>>>>>> used to make this distinction, nor can I think of one. >>>>>>> >>>>>>> [AA] I based this decision on the following criteria: If a >>>>>>> feature tag was potentially at all useful for an intermediary to >>>>>>> indicate it then include it in the registry. The ones not >>>>>>> included are either directly associated with the user >>>>>>> (intermediaries are not directly associated with the user) or >>>>>>> would only ever have one value (e.g automata). I am not sure >>>>>>> that every feature-capability indicator proposed to be registered >>>>>>> is actually useful but then I don't think every media feature tag >>>>>>> registered by RFC 3840 is either (I doubt very much if there are >>>>>>> implementation using the sip.application or sip.control feature >>>>>>> tags). I don't think RFC 3840 goes into a lot of details >>>>>>> justifying of ever registered media feature tag and specifying >>>>>>> the details of how they would be used either. I am willing to >>>>>>> remove any feature-capability indicators that are controversial exc= ept that I think we definitely need sip.extensions, sip.methods and sip.eve= nts. >>>>>>> There is a significant overhead to writing an >>>>>> d progressing internet drafts so my view is lets register all that >>>>>> might be remotely useful in the same document. >>>>>> >>>>>> The judgement of "useful" is reasonable. But I still can't discern >>>>>> what the use is from the iana registration descriptions. >>>>>> >>>>>>> For the ones that you have requested feature capability >>>>>>> indicators, I cannot figure out what using them would mean. For >>>>>>> example, when I see isFocus on a Contact header I know I am in a >>>>>>> conference, and that I can subscribe to the conference event >>>>>>> package at the contact URI. If I see isFocus in a Feature-Caps head= er, what does it mean? >>>>>>> What can I do once I know this? >>>>>>> >>>>>>> Section 5.14 of this draft says: >>>>>>> >>>>>>> This Feature-capability indicator indicates that the i= ntermediary >>>>>>> is a conference server, also known as a focus, and is = capable of >>>>>>> mixing together the media for all calls to the same UR= I. >>>>>>> ... >>>>>>> Examples of typical use: A conference bridge >>>>>>> indicating that it >>>>>>> is a conference bridge and is capable of acting as >>>>>>> a conference >>>>>>> focus for this session. >>>>>>> >>>>>>> [AA] the presence of isfocus in a Feature-Caps header field means >>>>>>> that a UA can initiate a conference by sending a REFER request to >>>>>>> the intermediary to invite another user and create a multi user >>>>>>> conference from the 1-1 session. >>>>>>> >>>>>>> Note that Feature-Caps doesn't indicate which entity has this >>>>>>> capability, only that something does. And since this would >>>>>>> presumably only be used if it wasn't the UAC of the request, >>>>>>> sending a subscribe to the contact address of the UAC wouldn't make= sense. >>>>>>> >>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I >>>>>>> consider this application specific and so this would be included >>>>>>> in a feature tag registered in the global tree as stated in the >>>>>>> draft "RFC 6809 [1] provides that addresses of intermediaries can >>>>>>> be communicated as a value of an associated feature-capability >>>>>>> indicator so it would be appropriate to define feature capability >>>>>>> indicators as part of the global tree to communicate the GRUU of >>>>>>> the intermediary and hence this is outside the scope of this >>>>>>> document." - RFC 6809 states " If additional data about a >>>>>>> supported feature needs to be conveyed, such as the address of >>>>>>> the SIP entity that indicated support of the feature, then the >>>>>>> feature definition needs to define a way to convey that >>>>>>> information as a value of the associated feature-capability >>>>>>> indicator." However I think the SIP specific capability >>>>>>> indicators such as methods, extensions and events should >>>>>>> appropriately be registered in the SIP tree not as proprietary >>>>>>> indicator >>>>>> s in the global tree. >>>>>> >>>>>> So you have defined a sip tree feature tag that is only useful in >>>>>> conjunction with another feature tag from the global tree. >>>>>> And the description of this feature tag doesn't even mention that. >>>>>> >>>>>> And this all implies a completely non-standard call model - doing >>>>>> conferencing in a way inconsistent with RFC 4579. >>>>>> >>>>>> ISTM that if 4579 doesn't work for you then you should be back >>>>>> proposing extensions/revisions to it. >>>>>> >>>>>>> If there is a conference bridge in the signaling path, then I >>>>>>> would expect it to be the UAC. >>>>>>> >>>>>>> [AA] Although a "standard" way to invoke a conference is to send >>>>>>> a REFER to the other UAs to invite them to the conference focus, >>>>>>> in many deployments a scenario exists where a call involves an >>>>>>> IP-PBX or Telephony Application Server (TAS) that can act as a >>>>>>> focus for the conference. A participant of a call can then create >>>>>>> a conference by sending a REFER request in dialog to the IP-PBX >>>>>>> or TAS to use 3PCC to Invite other users to a conference. Reasons f= or this are 1. >>>>>>> Not all UAs support REFER, >>>>>> >>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), >>>>>> but it *could become* a focus. >>>>>> >>>>>> The concept that a dialog may contain intermediaries that can be >>>>>> addressed to do stuff is not part of any sip standard that I am >>>>>> aware of. I don't care too much as long as the "stuff" is >>>>>> application stuff that is outside the scope of sip. But when it is >>>>>> alternative ways to do stuff that sip supports, then I get upset. >>>>>> >>>>>>> 2. Many SBCs reject REFER requests going outside domains because >>>>>>> of the potential for charging fraud (referring to a premium rate >>>>>>> number >>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to join >>>>>>> the conference may be charged for initiating the call when the >>>>>>> scenario is that the initiator of the conference should be charged. >>>>>>> 4. No need to obtain and distribute conference URIs. >>>>>>> Problem is how to achieve the same behavior without dialog reuse >>>>>>> which has been deprecated by RFC 6665? >>>>>> >>>>>> Then maybe the problem needs to be brought up, and a standard >>>>>> solution proposed, rather than simply enabling a proprietary mechani= sm. >>>>>> >>>>>>> As another example, consider section 5.1: >>>>>>> >>>>>>> Descrition: >>>>>>> This Feature-capability indicator indicates that the i= ntermediary >>>>>>> supports audio as a streaming media type. >>>>>>> ... >>>>>>> Examples of typical use: An IP PBX indicating that = it is >>>>>>> capable of accepting and initiating sessions with a= udio as a >>>>>>> streaming media type. >>>>>>> >>>>>>> This definition *implies* an assumption about the working >>>>>>> environment >>>>>>> - one that AFAIK is new. It implies that you need to know that >>>>>>> intermediaries support a media type before you can use it. Would >>>>>>> it be bad if there were no intermediaries, and so none indicated th= is? >>>>>>> What if some intermediary *did* indicate support, but some other >>>>>>> doesn't, but doesn't indicate that it doesn't? >>>>>>> >>>>>>> Bottom line: how would the presence or absence of this feature >>>>>>> tag affect subsequent usage? >>>>>>> >>>>>>> [AA] The absence of the streaming types does not indicate that >>>>>>> the intermediary does not support the media type and SDP offer >>>>>>> answer will ultimately determine what can or cannot be used if >>>>>>> another session is initiated involving the intermediary. However >>>>>>> the presence of the media type in a Feature-caps header field >>>>>>> does explictly confirm that the intermediary does support the >>>>>>> media type and in the scenario where a UA has a choice of >>>>>>> multiple intermediaries it could use for a conference it might >>>>>>> choose to use the one that explicitly indicates it supports the med= ia types the UA wants to use. >>>>>> >>>>>> So the UA will be able to discover that *some* intermediary >>>>>> supports media it is interested in. And it can tell that *some* >>>>>> intermediary says it is a focus. It doesn't know if they are the sam= e intermediary. >>>>>> >>>>>> And then via some other feature tag it obtains the URI of *some* >>>>>> intermediary on the signaling path. Or maybe it gets more than one >>>>>> of these. >>>>>> >>>>>> It then makes a leap of faith and conflates all those things, to >>>>>> determine that the URI identifies a focus that supports this media t= ype. >>>>>> >>>>>> Even then, exactly what does that mean? It may or may not mean >>>>>> that it supports mixing that media type in a conference. >>>>>> >>>>>>> As I stated already I don't care that much about these streaming >>>>>>> media types. >>>>>> >>>>>>> I could go on, but this is enough for now. >>>>>>> >>>>>>> [AA] My motivation for this is that currently 3GPP are updating >>>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>>> >>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with >>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather >>>>>>> than forwarding it all the way to the remote UA. >>>>>> >>>>>> And 6665 deprecates dial reuse in most of those cases. >>>>>> Without dialog reuse, the intermediaries don't get an opportunity >>>>>> to intercept those. >>>>>> >>>>>>> In order to know that an intermediary supports the target dialog >>>>>>> mechanism needed for a REFER request sent outside the dialog to >>>>>>> work we need sip.extensions as a feature-capability indicator. In >>>>>>> order to know that the needed event package is supported by the >>>>>>> intermediary so we can SUBSCROBE outside the dialog to an >>>>>>> intermediary we need sip.events as a feature-capability indicator. >>>>>> >>>>>> Then I think you should be back here with a problem statement and >>>>>> a request for how to get sip to solve it. >>>>>> >>>>>> And you should touch base with Christer on this. He may have a >>>>>> different opinion on the relevance of feature-caps as a solution. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>>> >>>>>>>> I have submitted a new draft to sipcore to register a number of >>>>>>>> feature capability indicators in the SIP tree (based upon some >>>>>>>> of the existing SIP media feature tags). The draft can be found at: >>>>>>>> >>>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators= -00. >>>>>>>> txt >>>>>>>> >>>>>>>> Since there will not be a sipcore session at IETF#88 can we >>>>>>>> have an offline discussion on how to progress this draft (which >>>>>>>> hopefully is fairly straightforward as it just registers feature >>>>>>>> capabilities indicators with IANA). I wouldn't want to have to >>>>>>>> wait until March next year for a decision on progressing this. >>>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>>> ---------------------------------------------------------------- >>>>>>>> --- >>>>>>>> - >>>>>>>> - This transmission (including any attachments) may contain >>>>>>>> confidential information, privileged material (including >>>>>>>> material protected by the solicitor-client or other applicable >>>>>>>> privileges), or constitute non-public information. Any use of >>>>>>>> this information by anyone other than the intended recipient is >>>>>>>> prohibited. If you have received this transmission in error, >>>>>>>> please immediately reply to the sender and delete this >>>>>>>> information from your system. Use, dissemination, distribution, >>>>>>>> or reproduction of this transmission by unintended recipients is n= ot authorized and may be unlawful. >>>>>>> >>>>>>> ----------------------------------------------------------------- >>>>>>> --- >>>>>>> - This transmission (including any attachments) may contain >>>>>>> confidential information, privileged material (including material >>>>>>> protected by the solicitor-client or other applicable >>>>>>> privileges), or constitute non-public information. Any use of >>>>>>> this information by anyone other than the intended recipient is >>>>>>> prohibited. If you have received this transmission in error, >>>>>>> please immediately reply to the sender and delete this >>>>>>> information from your system. Use, dissemination, distribution, >>>>>>> or reproduction of this transmission by unintended recipients is no= t authorized and may be unlawful. >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> -- This transmission (including any attachments) may contain >>>>> confidential information, privileged material (including material pro= tected by the solicitor-client or other applicable privileges), or constitu= te non-public information. Any use of this information by anyone other than= the intended recipient is prohibited. If you have received this transmissi= on in error, please immediately reply to the sender and delete this informa= tion from your system. Use, dissemination, distribution, or reproduction of= this transmission by unintended recipients is not authorized and may be un= lawful. >>>>> >>>>> >>>> >>>> -------------------------------------------------------------------- >>>> - This transmission (including any attachments) may contain >>>> confidential information, privileged material (including material prot= ected by the solicitor-client or other applicable privileges), or constitut= e non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this transmissio= n in error, please immediately reply to the sender and delete this informat= ion from your system. Use, dissemination, distribution, or reproduction of = this transmission by unintended recipients is not authorized and may be unl= awful. >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the solic= itor-client or other applicable privileges), or constitute non-public infor= mation. Any use of this information by anyone other than the intended recip= ient is prohibited. If you have received this transmission in error, please= immediately reply to the sender and delete this information from your syst= em. Use, dissemination, distribution, or reproduction of this transmission = by unintended recipients is not authorized and may be unlawful. >>> >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential i= nformation, privileged material (including material protected by the solici= tor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recipi= ent is prohibited. If you have received this transmission in error, please = immediately reply to the sender and delete this information from your syste= m. Use, dissemination, distribution, or reproduction of this transmission b= y unintended recipients is not authorized and may be unlawful. >> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338E3CD3AXMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

 <= /p>

If the semantic of g.x is= defined as the support for the session transfer capability and the URI at the entity including it for sending request to invoke the = session transfer  then the sip methods and sip extensions also include= d in the Feature-Caps header field also apply to the URI for session transf= er.

 <= /p>

Andrew<= /p>

 <= /p>

From: Christer= Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Friday, October 25, 2013 2:47 PM
To: Paul Kyzivat; Andrew Allen; SIPCORE
Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipc= ore-sip-tree-cap-indicators

 

Hi,

 

>> The next revisions will contain more de= tails on what each FCI (as Christer now calls them means).
>>
>> If some are not well understood I will remove them from the draft = (i.e. drop  the rat holes)
>>
>> I think my email exchange with Christer clarifies the other points= .
>>
>> Does this represent in principle a way forward?
>
> Maybe. We'll have to see how it goes.
>
> The challenge is, I think, that you want to bring in a bunch of the 38= 40
> feature tags, and have them mean something akin to what they do as
> feature tags when used as FCIs. But there needs to be some way to
> describe what *each* one means. It's not immediately clear to me how t= o
> do that.

As I said in another reply, I think that the FCI= s that use the +sip.method etc FCIs need to describe how they are used = in conjunction.

 

Example:

 

Feature-Caps: *;+g.x;+sip.methods=3D&quo= t;INVITE"

Feature-Caps: *;+g.y;+sip.methods=3D&quo= t;INVITE"

 

The FCI specifications for +g.x and +g.y=  need to describe how they are used together with +sip.method= s, if there is a relationship.

 

Otherwise +sip.methods only means that the e= ntity that inserted the FCIs support "INVITE".<= /p>

 

Regards,

 

Christer

 

 

 

 

 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: Friday, October 25, 2013 10:06 AM
> To: Andrew Allen; Go= nzalo.Camarillo@ericsson.com
> Cc: rlb@ipv.sx; adam@nostrum.com; chr= ister.holmberg@ericsson.com; mary.ietf.barnes@gmail.com
> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree= -cap-indicators
>
> Andrew,
>
> (I see this is still on the private thread. I'll reply here, but this = exchange should probably be reposted to the sipcore list as part of the pub= lic discussion of the draft.)
>
> On 10/24/13 10:41 PM, Andrew Allen wrote:
>>
>> Paul
>>
>> I am happy to do a revision with more details on the semantics of = the capability indicators. However I don't think it should be held to a ver= y much higher bar than the details in RFC 3840 and the other media feature = tag RFCs regarding the meaning of those tags.
>
> Keep in mind that the driving force for the definition of feature tags= in 3840 was in support of callerprefs (3841). So the context for the use o= f feature tags was that they would be placed on Contacts in REGISTER reques= ts. So you can interpret the definitions in that context: that a request sent to an AOR using callerprefs can affec= t the choice of which device the request goes to according to the capabilit= ies it wants. In that context audio, video, isfocus all make sense.
>
> Their use on Contacts in dialogs was derivative to that: because calle= rpref support is optional, there is no guarantee that the device you reach = via callerprefs will have the capabilities you requested. So the values in = the contact help confirm what you got.
>
> Of course they have since been used other ways. And the descriptions o= f them don't necessarily reflect that. IMO that is a defect due to the evol= ution of use.
>
> I'm looking for the same sort of context for use with the feature-caps= .
>
> In private discussion you indicated to me that you expected the featur= e caps to be grouped - with one of them giving the URI of the device that t= he other tags apply to. I guess this would end up looking something like: >
>     Feature-Caps: *;g.uri=3D"sip:foo@example.com";audio
>     Feature-Caps: *;g.uri=3D"sip:bar@example.com";audio;video;isfocus
>     Feature-Caps: *;g.uri=3D"sip:baz@example.com";text
>
> (I'm making up g.uri for the example.)
>
> And then presumably somebody on the signaling path will "shop&quo= t; in the feature caps for the capabilities it wants, and then send a reque= st to that URI, with the expectation that the UA responding will have those= capabilities.
>
>> The semantics should be no different than those of  the corre= sponding existing media  feature tag if it is present in the Contact h= eader.
>
> Note that 6809 says:
>
>      When a SIP entity receives a SIP request= , or response, that contains
>      one or more Feature-Caps header fields, = the feature-capability
>      indicators in the header field inform th= e entity about the features
>      and capabilities supported by entities i= n the SIP message signaling
>      path.  The procedure by which featu= res and capabilities are invoked
>      are outside the scope of this specificat= ion and MUST be described by
>      individual feature-capability indicator = specifications.
>
>      A Feature-Caps header field value cannot= convey the address of the
>      SIP entity that inserted the Feature-Cap= s header field.  If
>      additional data about a supported featur= e needs to be conveyed, such
>      as the address of the SIP entity that in= dicated support of the
>      feature, then the feature definition nee= ds to define a way to convey
>      that information as a value of the assoc= iated feature-capability
>      indicator.
>
> This was discussed at length while that RFC was under consideration. Y= et the definitions of the tags in *this* draft don't specify that.
>
>> The registration templates currently reference the RFC 3840 and th= e other RFCs that define the other media feature tags that correspond to th= ese feature capability indicators.
>
> And those definitions were written to be understood in the context of = 3840/3841. They make sense in that context, but not in *this* context.
>
>        Thanks,
>        Paul
>
>> But if more explicit detail is required then I can add some more t= ext  or alternatively remove the less important ones if they are going= to become rat holes. The ones I regard as really important and urgent are = sip.methods, sip.extensions and sip.events the meaning of which I think should be quite clear.
>>
>> Andrew
>>
>> ----- Original Message -----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time
>> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com
>> <Gonzalo.Cama= rillo@ericsson.com>
>> Cc: rlb@ipv.sx <rlb@ipv.sx>; adam@nostrum.com <adam@nostrum.com>;
>> christer.holmber= g@ericsson.com <ch= rister.holmberg@ericsson.com>;
>> mary.ietf.barnes@gma= il.com <mary.ietf.barn= es@gmail.com>; Paul Kyzivat
>> <pkyzivat@alum.mit.edu= >
>> Subject: Re: New sipcore draft submission
>> draft-allen-sipcore-sip-tree-cap-indicators
>>
>> On 10/24/13 4:07 PM, Andrew Allen wrote:
>>>
>>> Paul
>>>
>>> Ok
>>>
>>> So we are basically where I thought we were at when I submitte= d the draft.
>>>
>>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone= else who indicates interest) can have some offline discussion in Vancouver= on whether and how to progress this.
>>
>> As I indicated again on the sipcore list, I found the that the dra= ft
>> didn't explain nearly enough to allow meaningful use of these.
>> I know you replied, and I will continue the conversation there.
>> But I will be opposed to these until and unless the draft (and not= ably
>> the descriptions of the tags) are clear about how one could figure= out
>> what can do in the presence of the tags that one couldn't do witho= ut
>> them. AND, that the behavior that suggests doesn't "break&quo= t; sip. (E.g.,
>> by advocating a new and incompatible way to do something.)
>>
>> We can continue this on the sipcore list.
>>
>>       Thanks,
>>       Paul
>>
>>> Andrew
>>>
>>> ----- Original Message -----
>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Tim= e
>>> To: Andrew Allen; Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
>>> Cc: Richard Barnes (rlb@ipv.sx) <rlb@ipv.sx>; Adam Roach
>>> (adam@nostrum.com) <= ;adam@nostrum.com>; Christer Hol= mberg
>>> (christer.ho= lmberg@ericsson.com) <christer.holmberg@ericsson.com>;
>>> Mary Barnes (mar= y.ietf.barnes@gmail.com) <mary.ietf.barnes@gmail.com>
>>> Subject: Re: New sipcore draft submission
>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>
>>> On 10/24/13 2:17 PM, Andrew Allen wrote:
>>>> Paul
>>>>
>>>> That is fine. Although Mary in her reply to me seemed to i= ndicate maybe there was a possibility to use some of the DISPATCH spare tim= e for a SIPCORE session for this. Is that a possibility?
>>>>
>>>> I already replied to your post
>>>
>>> I discussed that with Adam. We decided we can't set a preceden= t to
>>> spin up a session to discuss a draft that hasn't had substanti= al
>>> (any) list discussion.
>>>
>>> But list discussion is always welcome.
>>>
>>>      Sorry,
>>>      Paul
>>>
>>>> Andrew
>>>>
>>>> -----Original Message-----
>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>> Sent: Thursday, October 24, 2013 1:31 PM
>>>> To: Andrew Allen; Gonzalo Camarillo
>>>> Cc: Richard Barnes (rlb@ipv.= sx); Adam Roach (adam@nostrum.com);
>>>> Christer Holmberg (christer.holmberg@ericsson.com)
>>>> Subject: Re: New sipcore draft submission
>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>
>>>> Andrew,
>>>>
>>>> I spoke with Mary about it, and we concluded that dispatch= isn't right for this. (In addition to being clearly sipcore, it didn't mee= t the deadline for dispatch.) I was wrong to encourage you that way.
>>>>
>>>> So no official live discussion in Vancouver. (But informal=
>>>> discussion
>>>> fine.)
>>>>
>>>> I'll resend my private comments to the sipcore list to kic= kstart some discussion there.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>> On 10/24/13 1:01 PM, Andrew Allen wrote:
>>>>> I just emailed Mary asking for agenda time. Should I c= ancel that request?
>>>>>
>>>>> -----Original Message-----
>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.co= m]
>>>>> Sent: Thursday, October 24, 2013 1:00 PM
>>>>> To: Paul Kyzivat
>>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx); Adam Roach
>>>>> (adam@nostrum.com<= /a>); Christer Holmberg
>>>>> (chr= ister.holmberg@ericsson.com)
>>>>> Subject: Re: New sipcore draft submission
>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>
>>>>> Hi Paul,
>>>>>
>>>>> given that you think this belongs to SIPCORE, I do not= see the need to run it through DISPATCH. Please, start technical discussio= ns on the draft on the SIPCORE list.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Gonzalo
>>>>>
>>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote:
>>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote:
>>>>>>> Paul
>>>>>>>
>>>>>>> Thanks for reviewing the draft already and giv= ing me early feedback.
>>>>>>>
>>>>>>> My responses below inline (prepended with [AA)= .
>>>>>>>
>>>>>>> Can I ask the ADs to determine ASAP if this ne= eds to go to
>>>>>>> DISPATCH first or not. As outlined below my vi= ew is that it is
>>>>>>> unnecessary for every little thing to go to DI= SPATCH as this just
>>>>>>> creates additional delay and overhead. If it i= s to be discussed
>>>>>>> in DISPATCH then I definitely would want agend= a time atIETF#88 for this.
>>>>>>
>>>>>> Having now seen Andrew's responses to my initial q= uestions, I
>>>>>> think this
>>>>>> *needs* to be carefully considered by sipcore. IMO= this has the
>>>>>> potential to create a dialect of sip that is incom= patible with
>>>>>> normal usage. (Maybe IMS has already done that. Bu= t this will make
>>>>>> it
>>>>>> worse.)
>>>>>>
>>>>>> But if there is a desire to discuss it publicly in= Vancouver then
>>>>>> dispatch is the opportunity and so some discussion= on the dispatch
>>>>>> list in advance of that would be appropriate.
>>>>>>
>>>>>> I'll defer to the ADs on this.
>>>>>>
>>>>>> More inline.
>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM
>>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx); Gonzalo Camarillo
>>>>>>> (Gonzalo.Camarillo@ericsson.com); Adam Roach (adam@nostrum.com)
>>>>>>> Subject: Re: New sipcore draft submission
>>>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>>>
>>>>>>> Andrew,
>>>>>>>
>>>>>>> On a legalistic note, its questionable to me w= hether this kind of
>>>>>>> action falls within the scope of sipcore. OTOH= , among existing
>>>>>>> wgs, sipcore is probably the best suited to di= scuss the proposal.
>>>>>>> We could take it to DISPATCH. I think DISPATCH= has extra time in
>>>>>>> its agenda for Vancouver, so that might be one= option for you.
>>>>>>> But then I don't know where dispatch would dis= patch it. It may be
>>>>>>> that AD sponsored is the best way to go.
>>>>>>>
>>>>>>> [AA] It seemed to me that sipcore was the righ= t place. This draft
>>>>>>> registers feature-capability indicators in a r= egistry that was
>>>>>>> created by a sipcore RFC (RFC 6809). You could= in my view make an
>>>>>>> argument that this should even have been done = as part of RFC 6809.
>>>>>>
>>>>>> If this was just a matter of registering some new = feature caps
>>>>>> that were not controversial, then I don't think si= pcore needs to be involved.
>>>>>>
>>>>>> But as I mentioned above, I do consider these cont= roversial.
>>>>>>
>>>>>>> Discussing it now on the dispatch list would b= e a good start
>>>>>>> toward discussing it at the dispatch session.<= br> >>>>>>>
>>>>>>> [AA] Can I ask the ADs to determine if this ne= eds to go to
>>>>>>> DISPATCH first or not. My view is that it is u= nnecessary for
>>>>>>> every little thing to go to DISPATCH as this j= ust creates additional delay and overhead.
>>>>>>> This just registers some indicators in an exis= ting IANA registry
>>>>>>> and is not (or should not be IMHO) a major pro= ject.
>>>>>>
>>>>>> To me this is a matter of whether you want to be o= pportunistic.
>>>>>> If this went to dispatch I would now recommend tha= t it be
>>>>>> dispatched to sipcore. So its a matter of whether = you want to talk
>>>>>> about it in the dispatch meeting.
>>>>>>
>>>>>>> Regarding substance, this draft troubles me. I= t takes
>>>>>>> feature-caps in exactly the direction that I f= ound most
>>>>>>> concerning about the mechanism in the first pl= ace.
>>>>>>>
>>>>>>> Your draft partitions the existing media featu= re tags into two
>>>>>>> sets
>>>>>>> - those that would be useful as feature-capabi= lity-indicators,
>>>>>>> and those that aren't. But I see no explanatio= n of the criteria
>>>>>>> used to make this distinction, nor can I think= of one.
>>>>>>>
>>>>>>> [AA] I based this decision on the following cr= iteria: If a
>>>>>>> feature tag was potentially at all useful for = an intermediary to
>>>>>>> indicate it then include it in the registry. T= he ones not
>>>>>>> included are either directly associated with t= he user
>>>>>>> (intermediaries are not  directly associa= ted with the user) or
>>>>>>> would only ever have one value (e.g automata).=   I am not sure
>>>>>>> that every feature-capability indicator propos= ed to be registered
>>>>>>> is actually useful but then I don't think ever= y media feature tag
>>>>>>> registered by RFC 3840 is either (I doubt very= much if there are
>>>>>>> implementation using the sip.application or si= p.control feature
>>>>>>> tags). I don't think RFC 3840 goes into a lot = of details
>>>>>>> justifying of ever registered media feature ta= g and specifying
>>>>>>> the details of how they would be used either.&= nbsp; I am willing to
>>>>>>> remove any feature-capability indicators that = are controversial except that I think we definitely need sip.extensions, si= p.methods and sip.events.
>>>>>>> There is a significant overhead to writing an<= br> >>>>>> d progressing internet drafts so my view is lets r= egister all that
>>>>>> might be remotely useful in the same document.
>>>>>>
>>>>>> The judgement of "useful" is reasonable.= But I still can't discern
>>>>>> what the use is from the iana registration descrip= tions.
>>>>>>
>>>>>>> For the ones that you have requested feature c= apability
>>>>>>> indicators, I cannot figure out what using the= m would mean. For
>>>>>>> example, when I see isFocus on a Contact heade= r I know I am in a
>>>>>>> conference, and that I can subscribe to the co= nference event
>>>>>>> package at the contact URI. If I see isFocus i= n a Feature-Caps header, what does it mean?
>>>>>>> What can I do once I know this?
>>>>>>>
>>>>>>> Section 5.14 of this draft says:
>>>>>>>
>>>>>>>        = ;      This Feature-capability indicator indicates= that the intermediary
>>>>>>>        = ;      is a conference server, also known as a foc= us, and is capable of
>>>>>>>        = ;      mixing together the media for all calls to = the same URI.
>>>>>>> ...
>>>>>>>        = ;         Examples of typical use: = A conference bridge
>>>>>>> indicating that it
>>>>>>>        = ;         is a conference bridge an= d is capable of acting as
>>>>>>> a conference
>>>>>>>        = ;         focus for this session. >>>>>>>
>>>>>>> [AA] the presence of isfocus in a Feature-Caps= header field means
>>>>>>> that a UA can initiate a conference by sending= a REFER request to
>>>>>>> the intermediary to invite another user and cr= eate a multi user
>>>>>>> conference from the 1-1 session.
>>>>>>>
>>>>>>> Note that Feature-Caps doesn't indicate which = entity has this
>>>>>>> capability, only that something does. And sinc= e this would
>>>>>>> presumably only be used if it wasn't the UAC o= f the request,
>>>>>>> sending a subscribe to the contact address of = the UAC wouldn't make sense.
>>>>>>>
>>>>>>> [AA] Yes the GRUU of the intermediary would be= needed but I
>>>>>>> consider this application specific and so this= would be included
>>>>>>> in a feature tag registered in the global tree= as stated in the
>>>>>>> draft "RFC 6809 [1] provides that address= es of intermediaries can
>>>>>>> be communicated as a value of an associated fe= ature-capability
>>>>>>> indicator so it would be appropriate to define= feature capability
>>>>>>> indicators as part of the global tree to commu= nicate the GRUU of
>>>>>>> the intermediary and hence this is outside the= scope of this
>>>>>>> document."  - RFC 6809 states "= If additional data about a
>>>>>>> supported feature needs to be conveyed, such a= s the address of
>>>>>>> the SIP entity that indicated support of the f= eature, then the
>>>>>>> feature definition needs to define a way to co= nvey that
>>>>>>> information as a value of the associated featu= re-capability
>>>>>>> indicator." However I think the SIP speci= fic capability
>>>>>>> indicators such as methods, extensions and eve= nts should
>>>>>>> appropriately be registered in the SIP tree no= t as proprietary
>>>>>>> indicator
>>>>>> s in the global tree.
>>>>>>
>>>>>> So you have defined a sip tree feature tag that is= only useful in
>>>>>> conjunction with another feature tag from the glob= al tree.
>>>>>> And the description of this feature tag doesn't ev= en mention that.
>>>>>>
>>>>>> And this all implies a completely non-standard cal= l model - doing
>>>>>> conferencing in a way inconsistent with RFC 4579.<= br> >>>>>>
>>>>>> ISTM that if 4579 doesn't work for you then you sh= ould be back
>>>>>> proposing extensions/revisions to it.
>>>>>>
>>>>>>> If there is a conference bridge in the signali= ng path, then I
>>>>>>> would expect it to be the UAC.
>>>>>>>
>>>>>>> [AA] Although a "standard" way to in= voke a conference is to send
>>>>>>> a REFER to the other UAs to invite them to the= conference focus,
>>>>>>> in many deployments a scenario exists where a = call involves an
>>>>>>> IP-PBX or Telephony Application Server (TAS) t= hat can act as a
>>>>>>> focus for the conference. A participant of a c= all can then create
>>>>>>> a conference by sending a REFER request in dia= log to the IP-PBX
>>>>>>> or TAS to use 3PCC to Invite other users to a = conference. Reasons for this are 1.
>>>>>>> Not all UAs support REFER,
>>>>>>
>>>>>> So you are saying the intermediary isn't a focus (= its a B2BUA),
>>>>>> but it *could become* a focus.
>>>>>>
>>>>>> The concept that a dialog may contain intermediari= es that can be
>>>>>> addressed to do stuff is not part of any sip stand= ard that I am
>>>>>> aware of. I don't care too much as long as the &qu= ot;stuff" is
>>>>>> application stuff that is outside the scope of sip= . But when it is
>>>>>> alternative ways to do stuff that sip supports, th= en I get upset.
>>>>>>
>>>>>>> 2. Many SBCs reject REFER requests going outsi= de domains because
>>>>>>> of the potential for charging fraud (referring= to a premium rate
>>>>>>> number
>>>>>>> etc) 3. A User receiving a REFER and then usin= g an INVITE to join
>>>>>>> the conference may be charged for initiating&n= bsp; the call when the
>>>>>>> scenario is that the initiator of the conferen= ce should be charged.
>>>>>>> 4. No need to obtain and distribute conference= URIs.
>>>>>>> Problem is how to achieve the same behavior wi= thout dialog reuse
>>>>>>> which has been deprecated by RFC 6665?
>>>>>>
>>>>>> Then maybe the problem needs to be brought up, and= a standard
>>>>>> solution proposed, rather than simply enabling a p= roprietary mechanism.
>>>>>>
>>>>>>> As another example, consider section 5.1:
>>>>>>>
>>>>>>>        = ;      Descrition:
>>>>>>>        = ;      This Feature-capability indicator indicates= that the intermediary
>>>>>>>        = ;      supports audio as a streaming media type. >>>>>>> ...
>>>>>>>        = ;         Examples of typical use: = An IP PBX indicating that it is
>>>>>>>        = ;         capable of accepting and = initiating sessions with audio as a
>>>>>>>        = ;         streaming media type.
>>>>>>>
>>>>>>> This definition *implies* an assumption about = the working
>>>>>>> environment
>>>>>>> - one that AFAIK is new. It implies that you n= eed to know that
>>>>>>> intermediaries support a media type before you= can use it. Would
>>>>>>> it be bad if there were no intermediaries, and= so none indicated this?
>>>>>>> What if some intermediary *did* indicate suppo= rt, but some other
>>>>>>> doesn't, but doesn't indicate that it doesn't?=
>>>>>>>
>>>>>>> Bottom line: how would the presence or absence= of this feature
>>>>>>> tag affect subsequent usage?
>>>>>>>
>>>>>>> [AA] The absence of the streaming types does n= ot indicate that
>>>>>>> the intermediary does not support the media ty= pe and SDP offer
>>>>>>> answer will ultimately determine what can or c= annot be used if
>>>>>>> another session is initiated involving the int= ermediary. However
>>>>>>> the presence of the media type in a Feature-ca= ps header field
>>>>>>> does explictly confirm that the intermediary d= oes support the
>>>>>>> media type and in the scenario where a UA has = a choice of
>>>>>>> multiple intermediaries it could use for a con= ference it might
>>>>>>> choose to use the one that explicitly indicate= s it supports the media types the UA wants to use.
>>>>>>
>>>>>> So the UA will be able to discover that *some* int= ermediary
>>>>>> supports media it is interested in. And it can tel= l that *some*
>>>>>> intermediary says it is a focus. It doesn't know i= f they are the same intermediary.
>>>>>>
>>>>>> And then via some other feature tag it obtains the= URI of *some*
>>>>>> intermediary on the signaling path. Or maybe it ge= ts more than one
>>>>>> of these.
>>>>>>
>>>>>> It then makes a leap of faith and conflates all th= ose things, to
>>>>>> determine that the URI identifies a focus that sup= ports this media type.
>>>>>>
>>>>>> Even then, exactly what does that mean? It may or = may not mean
>>>>>> that it supports mixing that media type in a confe= rence.
>>>>>>
>>>>>>> As I stated already I don't care that much abo= ut these streaming
>>>>>>> media types.
>>>>>>
>>>>>>> I could go on, but this is enough for now.
>>>>>>>
>>>>>>> [AA] My motivation for this is that currently = 3GPP are updating
>>>>>>> their specifications to use RFC 6665 instead o= f RFC 3265.
>>>>>>
>>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE = and REFER with
>>>>>>> intermediaries accepting the REFER or SUBSCRIB= E request rather
>>>>>>> than forwarding it all the way to the remote U= A.
>>>>>>
>>>>>> And 6665 deprecates dial reuse in most of those ca= ses.
>>>>>> Without dialog reuse, the intermediaries don't get= an opportunity
>>>>>> to intercept those.
>>>>>>
>>>>>>> In order to know that an intermediary supports= the target dialog
>>>>>>> mechanism  needed for a REFER request sen= t outside the dialog to
>>>>>>> work we need sip.extensions as a feature-capab= ility indicator. In
>>>>>>> order to know that the needed event package is= supported by the
>>>>>>> intermediary so we can SUBSCROBE outside the d= ialog to an
>>>>>>> intermediary we need sip.events as a feature-c= apability indicator.
>>>>>>
>>>>>> Then I think you should be back here with a proble= m statement and
>>>>>> a request for how to get sip to solve it.
>>>>>>
>>>>>> And you should touch base with Christer on this. H= e may have a
>>>>>> different opinion on the relevance of feature-caps= as a solution.
>>>>>>
>>>>>>        &nb= sp; Thanks,
>>>>>>        &nb= sp; Paul
>>>>>>
>>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote:
>>>>>>>> Adam, Paul, Richard, Gonzalo
>>>>>>>>
>>>>>>>> I have submitted a new draft to sipcore&nb= sp; to register a number of
>>>>>>>> feature capability indicators in the SIP t= ree (based upon some
>>>>>>>> of the existing SIP media feature tags). T= he draft can be found at:
>>>>>>>>
>>>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00.<= br> >>>>>>>> txt
>>>>>>>>
>>>>>>>> Since there will not be a sipcore session = at IETF#88  can we
>>>>>>>> have an offline discussion on how to progr= ess this draft (which
>>>>>>>> hopefully is fairly straightforward as it = just registers feature
>>>>>>>> capabilities indicators with IANA). I woul= dn't want to have to
>>>>>>>> wait until March next year for a decision = on progressing this.
>>>>>>>>
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>> ------------------------------------------= ----------------------
>>>>>>>> ---
>>>>>>>> -
>>>>>>>> - This transmission (including any attachm= ents) may contain
>>>>>>>> confidential information, privileged mater= ial (including
>>>>>>>> material protected by the solicitor-client= or other applicable
>>>>>>>> privileges), or constitute non-public info= rmation. Any use of
>>>>>>>> this information by anyone other than the = intended recipient is
>>>>>>>> prohibited. If you have received this tran= smission in error,
>>>>>>>> please immediately reply to the sender and= delete this
>>>>>>>> information from your system. Use, dissemi= nation, distribution,
>>>>>>>> or reproduction of this transmission by un= intended recipients is not authorized and may be unlawful.
>>>>>>>
>>>>>>> ----------------------------------------------= -------------------
>>>>>>> ---
>>>>>>> - This transmission (including any attachments= ) may contain
>>>>>>> confidential information, privileged material = (including material
>>>>>>> protected by the solicitor-client or other app= licable
>>>>>>> privileges), or constitute non-public informat= ion. Any use of
>>>>>>> this information by anyone other than the inte= nded recipient is
>>>>>>> prohibited. If you have received this transmis= sion in error,
>>>>>>> please immediately reply to the sender and del= ete this
>>>>>>> information from your system. Use, disseminati= on, distribution,
>>>>>>> or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------= -------------
>>>>> -- This transmission (including any attachments) may c= ontain
>>>>> confidential information, privileged material (includi= ng material protected by the solicitor-client or other applicable privilege= s), or constitute non-public information. Any use of this information by an= yone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, disseminat= ion, distribution, or reproduction of this transmission by unintended recip= ients is not authorized and may be unlawful.
>>>>>
>>>>>
>>>>
>>>> ----------------------------------------------------------= ----------
>>>> - This transmission (including any attachments) may contai= n
>>>> confidential information, privileged material (including m= aterial protected by the solicitor-client or other applicable privileges), = or constitute non-public information. Any use of this information by anyone= other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, disseminat= ion, distribution, or reproduction of this transmission by unintended recip= ients is not authorized and may be unlawful.
>>>>
>>>>
>>>
>>> --------------------------------------------------------------= -------
>>> This transmission (including any attachments) may contain conf= idential information, privileged material (including material protected by = the solicitor-client or other applicable privileges), or constitute non-pub= lic information. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>
>>>
>>
>> ------------------------------------------------------------------= ---
>> This transmission (including any attachments) may contain confiden= tial information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute non-public = information. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>
>>
>
> ---------------------------------------------------------------------<= br> > This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the soli= citor-client or other applicable privileges), or constitute non-public info= rmation. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>
>

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

---------------------------------------------------------------------
Th= is transmission (including any attachments) may contain confidential inform= ation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immed= iately reply to the sender and delete this information from your system. Us= e, dissemination, distribution, or reproduction of this transmission by uni= ntended recipients is not authorized and may be unlawful.
--_000_BBF5DDFE515C3946BC18D733B20DAD2338E3CD3AXMB104ADSrimnet_-- From christer.holmberg@ericsson.com Fri Oct 25 12:13:49 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F31611E8176 for ; Fri, 25 Oct 2013 12:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.707 X-Spam-Level: X-Spam-Status: No, score=-4.707 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44BTHYIRDwns for ; Fri, 25 Oct 2013 12:13:43 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6C49011E819A for ; Fri, 25 Oct 2013 12:13:40 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-e6-526ac2e34c75 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FE.38.16099.3E2CA625; Fri, 25 Oct 2013 21:13:39 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Fri, 25 Oct 2013 21:11:22 +0200 From: Christer Holmberg To: Andrew Allen , Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0bGFP58SWd7NsEuoIpBbiHeDAZoFv+AsgAACDAX//+IKgIAAI1IOgAABUkI= Date: Fri, 25 Oct 2013 19:11:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F713B@ESESSMB209.ericsson.se> References: <526A7ADF.8010106@alum.mit.edu> , <526ABAAC.1000304@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70BF@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4F713BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7tO7jQ1lBBvv2SFjcn7eV0WLFhgOs Fl9/bGJzYPb4+/4Dk8eshrXsHkuW/GQKYI7isklJzcksSy3St0vgypi1cy1rwaUTrBWXH8xi a2D8dZ+li5GTQ0LARGLd0U1QtpjEhXvr2boYuTiEBA4xSkxfNJMJwlnCKLH/82ugDAcHm4CF RPc/bZAGEYEcib6PaxhBbGGBRIlXV2YwQ8STJG5uuMcIYftJHPs8FWwBi4CqxL9nB8FqeAV8 Jf7uaWEFsYUETjFJtD/JAbE5BTwltjxtZgexGYEO+n5qDROIzSwgLnHryXwmiEMFJJbsOc8M YYtKvHz8jxXCVpL4seESC0R9vsSeS91sELsEJU7OfMIygVFkFpJRs5CUzUJSBhHXk7gxdQob hK0tsWzha2YIW1dixr9DUDXWEru3/WBEVrOAkWMVI3tuYmZOernhJkZgrB3c8lt3B+OpcyKH GKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwNjhFf56vqfNwxtJHYqxrDut 3s2TFtDYcd/qkPmRrmLnB6cuPowME9e/1dQo8ev7FN+nL38t6Izm/Mgs2XpX1yB8HffeT9n/ YiMDSs4naT1eecyAqUbi/m7BzvqnFeyHWhIL/55vNRXf3fzF9Fkxa5GfZKdVIMtpA/2b7Fvf /97yUSdw9Ru3k0osxRmJhlrMRcWJAEfyobWDAgAA Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:13:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4F713BESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >If the semantic of g.x is defined as the support for the session transfer = capability and the URI at the entity including it for sending request to in= voke >the session transfer then the sip methods and sip extensions also include= d in the Feature-Caps header field also apply to the URI for session transf= er. Even if the semantic of g.x explicitly says that the address points to the = same entity that indicates support of the feature, I still think the g.x FC= I specification should describe how g.x is used together with other FCIs (e= .g. +sip.methods). That will help implementors to determine whether they can include g.y in th= e same Feature-Caps header field as g.x or not, if g.y also uses +sip.metho= ds. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, October 25, 2013 2:47 PM To: Paul Kyzivat; Andrew Allen; SIPCORE Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators Hi, >> The next revisions will contain more details on what each FCI (as Christ= er now calls them means). >> >> If some are not well understood I will remove them from the draft (i.e. = drop the rat holes) >> >> I think my email exchange with Christer clarifies the other points. >> >> Does this represent in principle a way forward? > > Maybe. We'll have to see how it goes. > > The challenge is, I think, that you want to bring in a bunch of the 3840 > feature tags, and have them mean something akin to what they do as > feature tags when used as FCIs. But there needs to be some way to > describe what *each* one means. It's not immediately clear to me how to > do that. As I said in another reply, I think that the FCIs that use the +sip.method = etc FCIs need to describe how they are used in conjunction. Example: Feature-Caps: *;+g.x;+sip.methods=3D"INVITE" Feature-Caps: *;+g.y;+sip.methods=3D"INVITE" The FCI specifications for +g.x and +g.y need to describe how they are used= together with +sip.methods, if there is a relationship. Otherwise +sip.methods only means that the entity that inserted the FCIs su= pport "INVITE". Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, October 25, 2013 10:06 AM > To: Andrew Allen; Gonzalo.Camarillo@ericsson.com > Cc: rlb@ipv.sx; adam@nostrum.com; christer.holmberg@ericsson.com;= mary.ietf.barnes@gmail.com > Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-ca= p-indicators > > Andrew, > > (I see this is still on the private thread. I'll reply here, but this exc= hange should probably be reposted to the sipcore list as part of the public= discussion of the draft.) > > On 10/24/13 10:41 PM, Andrew Allen wrote: >> >> Paul >> >> I am happy to do a revision with more details on the semantics of the ca= pability indicators. However I don't think it should be held to a very much= higher bar than the details in RFC 3840 and the other media feature tag RF= Cs regarding the meaning of those tags. > > Keep in mind that the driving force for the definition of feature tags in= 3840 was in support of callerprefs (3841). So the context for the use of f= eature tags was that they would be placed on Contacts in REGISTER requests.= So you can interpret the definitions in that context: that a request sent = to an AOR using callerprefs can affect the choice of which device the reque= st goes to according to the capabilities it wants. In that context audio, v= ideo, isfocus all make sense. > > Their use on Contacts in dialogs was derivative to that: because callerpr= ef support is optional, there is no guarantee that the device you reach via= callerprefs will have the capabilities you requested. So the values in the= contact help confirm what you got. > > Of course they have since been used other ways. And the descriptions of t= hem don't necessarily reflect that. IMO that is a defect due to the evoluti= on of use. > > I'm looking for the same sort of context for use with the feature-caps. > > In private discussion you indicated to me that you expected the feature c= aps to be grouped - with one of them giving the URI of the device that the = other tags apply to. I guess this would end up looking something like: > > Feature-Caps: *;g.uri=3D"sip:foo@example.com";audio > Feature-Caps: *;g.uri=3D"sip:bar@example.com";audio;video;isfocus > Feature-Caps: *;g.uri=3D"sip:baz@example.com";text > > (I'm making up g.uri for the example.) > > And then presumably somebody on the signaling path will "shop" in the fea= ture caps for the capabilities it wants, and then send a request to that UR= I, with the expectation that the UA responding will have those capabilities= . > >> The semantics should be no different than those of the corresponding ex= isting media feature tag if it is present in the Contact header. > > Note that 6809 says: > > When a SIP entity receives a SIP request, or response, that contains > one or more Feature-Caps header fields, the feature-capability > indicators in the header field inform the entity about the features > and capabilities supported by entities in the SIP message signaling > path. The procedure by which features and capabilities are invoked > are outside the scope of this specification and MUST be described by > individual feature-capability indicator specifications. > > A Feature-Caps header field value cannot convey the address of the > SIP entity that inserted the Feature-Caps header field. If > additional data about a supported feature needs to be conveyed, such > as the address of the SIP entity that indicated support of the > feature, then the feature definition needs to define a way to convey > that information as a value of the associated feature-capability > indicator. > > This was discussed at length while that RFC was under consideration. Yet = the definitions of the tags in *this* draft don't specify that. > >> The registration templates currently reference the RFC 3840 and the othe= r RFCs that define the other media feature tags that correspond to these fe= ature capability indicators. > > And those definitions were written to be understood in the context of 384= 0/3841. They make sense in that context, but not in *this* context. > > Thanks, > Paul > >> But if more explicit detail is required then I can add some more text o= r alternatively remove the less important ones if they are going to become = rat holes. The ones I regard as really important and urgent are sip.methods= , sip.extensions and sip.events the meaning of which I think should be quit= e clear. >> >> Andrew >> >> ----- Original Message ----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com >> > >> Cc: rlb@ipv.sx >; adam@= nostrum.com >; >> christer.holmberg@ericsson.com >; >> mary.ietf.barnes@gmail.com >; Paul Kyzivat >> > >> Subject: Re: New sipcore draft submission >> draft-allen-sipcore-sip-tree-cap-indicators >> >> On 10/24/13 4:07 PM, Andrew Allen wrote: >>> >>> Paul >>> >>> Ok >>> >>> So we are basically where I thought we were at when I submitted the dra= ft. >>> >>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who= indicates interest) can have some offline discussion in Vancouver on wheth= er and how to progress this. >> >> As I indicated again on the sipcore list, I found the that the draft >> didn't explain nearly enough to allow meaningful use of these. >> I know you replied, and I will continue the conversation there. >> But I will be opposed to these until and unless the draft (and notably >> the descriptions of the tags) are clear about how one could figure out >> what can do in the presence of the tags that one couldn't do without >> them. AND, that the behavior that suggests doesn't "break" sip. (E.g., >> by advocating a new and incompatible way to do something.) >> >> We can continue this on the sipcore list. >> >> Thanks, >> Paul >> >>> Andrew >>> >>> ----- Original Message ----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >>> To: Andrew Allen; Gonzalo Camarillo > >>> Cc: Richard Barnes (rlb@ipv.sx) >; Adam Roach >>> (adam@nostrum.com) >; Christer Holmberg >>> (christer.holmberg@ericsson.com)= >; >>> Mary Barnes (mary.ietf.barnes@gmail.com) > >>> Subject: Re: New sipcore draft submission >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> On 10/24/13 2:17 PM, Andrew Allen wrote: >>>> Paul >>>> >>>> That is fine. Although Mary in her reply to me seemed to indicate mayb= e there was a possibility to use some of the DISPATCH spare time for a SIPC= ORE session for this. Is that a possibility? >>>> >>>> I already replied to your post >>> >>> I discussed that with Adam. We decided we can't set a precedent to >>> spin up a session to discuss a draft that hasn't had substantial >>> (any) list discussion. >>> >>> But list discussion is always welcome. >>> >>> Sorry, >>> Paul >>> >>>> Andrew >>>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, October 24, 2013 1:31 PM >>>> To: Andrew Allen; Gonzalo Camarillo >>>> Cc: Richard Barnes (rlb@ipv.sx); Adam Roach (adam@n= ostrum.com); >>>> Christer Holmberg (christer.holmberg@ericsson.com) >>>> Subject: Re: New sipcore draft submission >>>> draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> Andrew, >>>> >>>> I spoke with Mary about it, and we concluded that dispatch isn't right= for this. (In addition to being clearly sipcore, it didn't meet the deadli= ne for dispatch.) I was wrong to encourage you that way. >>>> >>>> So no official live discussion in Vancouver. (But informal >>>> discussion >>>> fine.) >>>> >>>> I'll resend my private comments to the sipcore list to kickstart some = discussion there. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>>> I just emailed Mary asking for agenda time. Should I cancel that requ= est? >>>>> >>>>> -----Original Message----- >>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>> Sent: Thursday, October 24, 2013 1:00 PM >>>>> To: Paul Kyzivat >>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx); Ada= m Roach >>>>> (adam@nostrum.com); Christer Holmberg >>>>> (christer.holmberg@ericsson.com) >>>>> Subject: Re: New sipcore draft submission >>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>> >>>>> Hi Paul, >>>>> >>>>> given that you think this belongs to SIPCORE, I do not see the need t= o run it through DISPATCH. Please, start technical discussions on the draft= on the SIPCORE list. >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>>> Paul >>>>>>> >>>>>>> Thanks for reviewing the draft already and giving me early feedback= . >>>>>>> >>>>>>> My responses below inline (prepended with [AA). >>>>>>> >>>>>>> Can I ask the ADs to determine ASAP if this needs to go to >>>>>>> DISPATCH first or not. As outlined below my view is that it is >>>>>>> unnecessary for every little thing to go to DISPATCH as this just >>>>>>> creates additional delay and overhead. If it is to be discussed >>>>>>> in DISPATCH then I definitely would want agenda time atIETF#88 for = this. >>>>>> >>>>>> Having now seen Andrew's responses to my initial questions, I >>>>>> think this >>>>>> *needs* to be carefully considered by sipcore. IMO this has the >>>>>> potential to create a dialect of sip that is incompatible with >>>>>> normal usage. (Maybe IMS has already done that. But this will make >>>>>> it >>>>>> worse.) >>>>>> >>>>>> But if there is a desire to discuss it publicly in Vancouver then >>>>>> dispatch is the opportunity and so some discussion on the dispatch >>>>>> list in advance of that would be appropriate. >>>>>> >>>>>> I'll defer to the ADs on this. >>>>>> >>>>>> More inline. >>>>>> >>>>>>> Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx); G= onzalo Camarillo >>>>>>> (Gonzalo.Camarillo@ericsson.com); Adam Roach (adam@nostrum.com) >>>>>>> Subject: Re: New sipcore draft submission >>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>> >>>>>>> Andrew, >>>>>>> >>>>>>> On a legalistic note, its questionable to me whether this kind of >>>>>>> action falls within the scope of sipcore. OTOH, among existing >>>>>>> wgs, sipcore is probably the best suited to discuss the proposal. >>>>>>> We could take it to DISPATCH. I think DISPATCH has extra time in >>>>>>> its agenda for Vancouver, so that might be one option for you. >>>>>>> But then I don't know where dispatch would dispatch it. It may be >>>>>>> that AD sponsored is the best way to go. >>>>>>> >>>>>>> [AA] It seemed to me that sipcore was the right place. This draft >>>>>>> registers feature-capability indicators in a registry that was >>>>>>> created by a sipcore RFC (RFC 6809). You could in my view make an >>>>>>> argument that this should even have been done as part of RFC 6809. >>>>>> >>>>>> If this was just a matter of registering some new feature caps >>>>>> that were not controversial, then I don't think sipcore needs to be = involved. >>>>>> >>>>>> But as I mentioned above, I do consider these controversial. >>>>>> >>>>>>> Discussing it now on the dispatch list would be a good start >>>>>>> toward discussing it at the dispatch session. >>>>>>> >>>>>>> [AA] Can I ask the ADs to determine if this needs to go to >>>>>>> DISPATCH first or not. My view is that it is unnecessary for >>>>>>> every little thing to go to DISPATCH as this just creates additiona= l delay and overhead. >>>>>>> This just registers some indicators in an existing IANA registry >>>>>>> and is not (or should not be IMHO) a major project. >>>>>> >>>>>> To me this is a matter of whether you want to be opportunistic. >>>>>> If this went to dispatch I would now recommend that it be >>>>>> dispatched to sipcore. So its a matter of whether you want to talk >>>>>> about it in the dispatch meeting. >>>>>> >>>>>>> Regarding substance, this draft troubles me. It takes >>>>>>> feature-caps in exactly the direction that I found most >>>>>>> concerning about the mechanism in the first place. >>>>>>> >>>>>>> Your draft partitions the existing media feature tags into two >>>>>>> sets >>>>>>> - those that would be useful as feature-capability-indicators, >>>>>>> and those that aren't. But I see no explanation of the criteria >>>>>>> used to make this distinction, nor can I think of one. >>>>>>> >>>>>>> [AA] I based this decision on the following criteria: If a >>>>>>> feature tag was potentially at all useful for an intermediary to >>>>>>> indicate it then include it in the registry. The ones not >>>>>>> included are either directly associated with the user >>>>>>> (intermediaries are not directly associated with the user) or >>>>>>> would only ever have one value (e.g automata). I am not sure >>>>>>> that every feature-capability indicator proposed to be registered >>>>>>> is actually useful but then I don't think every media feature tag >>>>>>> registered by RFC 3840 is either (I doubt very much if there are >>>>>>> implementation using the sip.application or sip.control feature >>>>>>> tags). I don't think RFC 3840 goes into a lot of details >>>>>>> justifying of ever registered media feature tag and specifying >>>>>>> the details of how they would be used either. I am willing to >>>>>>> remove any feature-capability indicators that are controversial exc= ept that I think we definitely need sip.extensions, sip.methods and sip.eve= nts. >>>>>>> There is a significant overhead to writing an >>>>>> d progressing internet drafts so my view is lets register all that >>>>>> might be remotely useful in the same document. >>>>>> >>>>>> The judgement of "useful" is reasonable. But I still can't discern >>>>>> what the use is from the iana registration descriptions. >>>>>> >>>>>>> For the ones that you have requested feature capability >>>>>>> indicators, I cannot figure out what using them would mean. For >>>>>>> example, when I see isFocus on a Contact header I know I am in a >>>>>>> conference, and that I can subscribe to the conference event >>>>>>> package at the contact URI. If I see isFocus in a Feature-Caps head= er, what does it mean? >>>>>>> What can I do once I know this? >>>>>>> >>>>>>> Section 5.14 of this draft says: >>>>>>> >>>>>>> This Feature-capability indicator indicates that the i= ntermediary >>>>>>> is a conference server, also known as a focus, and is = capable of >>>>>>> mixing together the media for all calls to the same UR= I. >>>>>>> ... >>>>>>> Examples of typical use: A conference bridge >>>>>>> indicating that it >>>>>>> is a conference bridge and is capable of acting as >>>>>>> a conference >>>>>>> focus for this session. >>>>>>> >>>>>>> [AA] the presence of isfocus in a Feature-Caps header field means >>>>>>> that a UA can initiate a conference by sending a REFER request to >>>>>>> the intermediary to invite another user and create a multi user >>>>>>> conference from the 1-1 session. >>>>>>> >>>>>>> Note that Feature-Caps doesn't indicate which entity has this >>>>>>> capability, only that something does. And since this would >>>>>>> presumably only be used if it wasn't the UAC of the request, >>>>>>> sending a subscribe to the contact address of the UAC wouldn't make= sense. >>>>>>> >>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I >>>>>>> consider this application specific and so this would be included >>>>>>> in a feature tag registered in the global tree as stated in the >>>>>>> draft "RFC 6809 [1] provides that addresses of intermediaries can >>>>>>> be communicated as a value of an associated feature-capability >>>>>>> indicator so it would be appropriate to define feature capability >>>>>>> indicators as part of the global tree to communicate the GRUU of >>>>>>> the intermediary and hence this is outside the scope of this >>>>>>> document." - RFC 6809 states " If additional data about a >>>>>>> supported feature needs to be conveyed, such as the address of >>>>>>> the SIP entity that indicated support of the feature, then the >>>>>>> feature definition needs to define a way to convey that >>>>>>> information as a value of the associated feature-capability >>>>>>> indicator." However I think the SIP specific capability >>>>>>> indicators such as methods, extensions and events should >>>>>>> appropriately be registered in the SIP tree not as proprietary >>>>>>> indicator >>>>>> s in the global tree. >>>>>> >>>>>> So you have defined a sip tree feature tag that is only useful in >>>>>> conjunction with another feature tag from the global tree. >>>>>> And the description of this feature tag doesn't even mention that. >>>>>> >>>>>> And this all implies a completely non-standard call model - doing >>>>>> conferencing in a way inconsistent with RFC 4579. >>>>>> >>>>>> ISTM that if 4579 doesn't work for you then you should be back >>>>>> proposing extensions/revisions to it. >>>>>> >>>>>>> If there is a conference bridge in the signaling path, then I >>>>>>> would expect it to be the UAC. >>>>>>> >>>>>>> [AA] Although a "standard" way to invoke a conference is to send >>>>>>> a REFER to the other UAs to invite them to the conference focus, >>>>>>> in many deployments a scenario exists where a call involves an >>>>>>> IP-PBX or Telephony Application Server (TAS) that can act as a >>>>>>> focus for the conference. A participant of a call can then create >>>>>>> a conference by sending a REFER request in dialog to the IP-PBX >>>>>>> or TAS to use 3PCC to Invite other users to a conference. Reasons f= or this are 1. >>>>>>> Not all UAs support REFER, >>>>>> >>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), >>>>>> but it *could become* a focus. >>>>>> >>>>>> The concept that a dialog may contain intermediaries that can be >>>>>> addressed to do stuff is not part of any sip standard that I am >>>>>> aware of. I don't care too much as long as the "stuff" is >>>>>> application stuff that is outside the scope of sip. But when it is >>>>>> alternative ways to do stuff that sip supports, then I get upset. >>>>>> >>>>>>> 2. Many SBCs reject REFER requests going outside domains because >>>>>>> of the potential for charging fraud (referring to a premium rate >>>>>>> number >>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to join >>>>>>> the conference may be charged for initiating the call when the >>>>>>> scenario is that the initiator of the conference should be charged. >>>>>>> 4. No need to obtain and distribute conference URIs. >>>>>>> Problem is how to achieve the same behavior without dialog reuse >>>>>>> which has been deprecated by RFC 6665? >>>>>> >>>>>> Then maybe the problem needs to be brought up, and a standard >>>>>> solution proposed, rather than simply enabling a proprietary mechani= sm. >>>>>> >>>>>>> As another example, consider section 5.1: >>>>>>> >>>>>>> Descrition: >>>>>>> This Feature-capability indicator indicates that the i= ntermediary >>>>>>> supports audio as a streaming media type. >>>>>>> ... >>>>>>> Examples of typical use: An IP PBX indicating that = it is >>>>>>> capable of accepting and initiating sessions with a= udio as a >>>>>>> streaming media type. >>>>>>> >>>>>>> This definition *implies* an assumption about the working >>>>>>> environment >>>>>>> - one that AFAIK is new. It implies that you need to know that >>>>>>> intermediaries support a media type before you can use it. Would >>>>>>> it be bad if there were no intermediaries, and so none indicated th= is? >>>>>>> What if some intermediary *did* indicate support, but some other >>>>>>> doesn't, but doesn't indicate that it doesn't? >>>>>>> >>>>>>> Bottom line: how would the presence or absence of this feature >>>>>>> tag affect subsequent usage? >>>>>>> >>>>>>> [AA] The absence of the streaming types does not indicate that >>>>>>> the intermediary does not support the media type and SDP offer >>>>>>> answer will ultimately determine what can or cannot be used if >>>>>>> another session is initiated involving the intermediary. However >>>>>>> the presence of the media type in a Feature-caps header field >>>>>>> does explictly confirm that the intermediary does support the >>>>>>> media type and in the scenario where a UA has a choice of >>>>>>> multiple intermediaries it could use for a conference it might >>>>>>> choose to use the one that explicitly indicates it supports the med= ia types the UA wants to use. >>>>>> >>>>>> So the UA will be able to discover that *some* intermediary >>>>>> supports media it is interested in. And it can tell that *some* >>>>>> intermediary says it is a focus. It doesn't know if they are the sam= e intermediary. >>>>>> >>>>>> And then via some other feature tag it obtains the URI of *some* >>>>>> intermediary on the signaling path. Or maybe it gets more than one >>>>>> of these. >>>>>> >>>>>> It then makes a leap of faith and conflates all those things, to >>>>>> determine that the URI identifies a focus that supports this media t= ype. >>>>>> >>>>>> Even then, exactly what does that mean? It may or may not mean >>>>>> that it supports mixing that media type in a conference. >>>>>> >>>>>>> As I stated already I don't care that much about these streaming >>>>>>> media types. >>>>>> >>>>>>> I could go on, but this is enough for now. >>>>>>> >>>>>>> [AA] My motivation for this is that currently 3GPP are updating >>>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>>> >>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with >>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather >>>>>>> than forwarding it all the way to the remote UA. >>>>>> >>>>>> And 6665 deprecates dial reuse in most of those cases. >>>>>> Without dialog reuse, the intermediaries don't get an opportunity >>>>>> to intercept those. >>>>>> >>>>>>> In order to know that an intermediary supports the target dialog >>>>>>> mechanism needed for a REFER request sent outside the dialog to >>>>>>> work we need sip.extensions as a feature-capability indicator. In >>>>>>> order to know that the needed event package is supported by the >>>>>>> intermediary so we can SUBSCROBE outside the dialog to an >>>>>>> intermediary we need sip.events as a feature-capability indicator. >>>>>> >>>>>> Then I think you should be back here with a problem statement and >>>>>> a request for how to get sip to solve it. >>>>>> >>>>>> And you should touch base with Christer on this. He may have a >>>>>> different opinion on the relevance of feature-caps as a solution. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>>> >>>>>>>> I have submitted a new draft to sipcore to register a number of >>>>>>>> feature capability indicators in the SIP tree (based upon some >>>>>>>> of the existing SIP media feature tags). The draft can be found at= : >>>>>>>> >>>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators= -00. >>>>>>>> txt >>>>>>>> >>>>>>>> Since there will not be a sipcore session at IETF#88 can we >>>>>>>> have an offline discussion on how to progress this draft (which >>>>>>>> hopefully is fairly straightforward as it just registers feature >>>>>>>> capabilities indicators with IANA). I wouldn't want to have to >>>>>>>> wait until March next year for a decision on progressing this. >>>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>>> ---------------------------------------------------------------- >>>>>>>> --- >>>>>>>> - >>>>>>>> - This transmission (including any attachments) may contain >>>>>>>> confidential information, privileged material (including >>>>>>>> material protected by the solicitor-client or other applicable >>>>>>>> privileges), or constitute non-public information. Any use of >>>>>>>> this information by anyone other than the intended recipient is >>>>>>>> prohibited. If you have received this transmission in error, >>>>>>>> please immediately reply to the sender and delete this >>>>>>>> information from your system. Use, dissemination, distribution, >>>>>>>> or reproduction of this transmission by unintended recipients is n= ot authorized and may be unlawful. >>>>>>> >>>>>>> ----------------------------------------------------------------- >>>>>>> --- >>>>>>> - This transmission (including any attachments) may contain >>>>>>> confidential information, privileged material (including material >>>>>>> protected by the solicitor-client or other applicable >>>>>>> privileges), or constitute non-public information. Any use of >>>>>>> this information by anyone other than the intended recipient is >>>>>>> prohibited. If you have received this transmission in error, >>>>>>> please immediately reply to the sender and delete this >>>>>>> information from your system. Use, dissemination, distribution, >>>>>>> or reproduction of this transmission by unintended recipients is no= t authorized and may be unlawful. >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> -- This transmission (including any attachments) may contain >>>>> confidential information, privileged material (including material pro= tected by the solicitor-client or other applicable privileges), or constitu= te non-public information. Any use of this information by anyone other than= the intended recipient is prohibited. If you have received this transmissi= on in error, please immediately reply to the sender and delete this informa= tion from your system. Use, dissemination, distribution, or reproduction of= this transmission by unintended recipients is not authorized and may be un= lawful. >>>>> >>>>> >>>> >>>> -------------------------------------------------------------------- >>>> - This transmission (including any attachments) may contain >>>> confidential information, privileged material (including material prot= ected by the solicitor-client or other applicable privileges), or constitut= e non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this transmissio= n in error, please immediately reply to the sender and delete this informat= ion from your system. Use, dissemination, distribution, or reproduction of = this transmission by unintended recipients is not authorized and may be unl= awful. >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the solic= itor-client or other applicable privileges), or constitute non-public infor= mation. Any use of this information by anyone other than the intended recip= ient is prohibited. If you have received this transmission in error, please= immediately reply to the sender and delete this information from your syst= em. Use, dissemination, distribution, or reproduction of this transmission = by unintended recipients is not authorized and may be unlawful. >>> >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential i= nformation, privileged material (including material protected by the solici= tor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recipi= ent is prohibited. If you have received this transmission in error, please = immediately reply to the sender and delete this information from your syste= m. Use, dissemination, distribution, or reproduction of this transmission b= y unintended recipients is not authorized and may be unlawful. >> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_7594FB04B1934943A5C02806D1A2204B1C4F713BESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

 

>If the s= emantic of g.x is defined as the support for the session transfer capabilit= y and the URI at the entity including it for sending request to invoke

>the sess= ion transfer  then the sip methods and sip extensions also included in= the Feature-Caps header field also apply to the URI for session transfer.

 = ;

Even if the = semantic of g.x explicitly says that the address points to the same entity = that indicates support of the feature, I still think the g.x FCI specification should describe how g.x is used together with other = FCIs (e.g. +sip.methods).

 = ;

That will he= lp implementors to determine whether they can include g.y in the same Featu= re-Caps header field as g.x or not, if g.y also uses +sip.methods.=

 = ;

Regards,

 = ;

Christer

 = ;

 

From: Chri= ster Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Friday, October 25, 2013 2:47 PM
To: Paul Kyzivat; Andrew Allen; SIPCORE
Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipc= ore-sip-tree-cap-indicators

 

Hi,

 

>> The next revisions will contain mor= e details on what each FCI (as Christer now calls them means).
>>
>> If some are not well understood I will remove them from the draft = (i.e. drop  the rat holes)
>>
>> I think my email exchange with Christer clarifies the other points= .
>>
>> Does this represent in principle a way forward?
>
> Maybe. We'll have to see how it goes.
>
> The challenge is, I think, that you want to bring in a bunch of the 38= 40
> feature tags, and have them mean something akin to what they do as > feature tags when used as FCIs. But there needs to be some way to
> describe what *each* one means. It's not immediately clear to me how t= o
> do that.

As I said in another reply, I think that the= FCIs that use the +sip.method etc FCIs need to describe how they are u= sed in conjunction.

 

Example:

 

Feature-Caps: *;+g.x;+sip.methods=3D= "INVITE"

Feature-Caps: *;+g.y;+sip.methods=3D= "INVITE"

 

The FCI specifications for +g.x and += ;g.y need to describe how they are used together with +sip.me= thods, if there is a relationship.

 

Otherwise +sip.methods only means that t= he entity that inserted the FCIs support "INVITE".

 

Regards,

 

Christer

 

 

 

 

 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
> Sent: Friday, October 25, 2013 10:06 AM
> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com
> Cc: rlb@ipv.sx; adam@nostrum.com; christer.holmberg@ericsson.com; mary.ietf.barnes@gmail.com
> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree= -cap-indicators
>
> Andrew,
>
> (I see this is still on the private thread. I'll reply here, but this = exchange should probably be reposted to the sipcore list as part of the pub= lic discussion of the draft.)
>
> On 10/24/13 10:41 PM, Andrew Allen wrote:
>>
>> Paul
>>
>> I am happy to do a revision with more details on the semantics of = the capability indicators. However I don't think it should be held to a ver= y much higher bar than the details in RFC 3840 and the other media feature = tag RFCs regarding the meaning of those tags.
>
> Keep in mind that the driving force for the definition of feature tags= in 3840 was in support of callerprefs (3841). So the context for the use o= f feature tags was that they would be placed on Contacts in REGISTER reques= ts. So you can interpret the definitions in that context: that a request sent to an AOR using callerprefs can affec= t the choice of which device the request goes to according to the capabilit= ies it wants. In that context audio, video, isfocus all make sense.
>
> Their use on Contacts in dialogs was derivative to that: because calle= rpref support is optional, there is no guarantee that the device you reach = via callerprefs will have the capabilities you requested. So the values in = the contact help confirm what you got.
>
> Of course they have since been used other ways. And the descriptions o= f them don't necessarily reflect that. IMO that is a defect due to the evol= ution of use.
>
> I'm looking for the same sort of context for use with the feature-caps= .
>
> In private discussion you indicated to me that you expected the featur= e caps to be grouped - with one of them giving the URI of the device that t= he other tags apply to. I guess this would end up looking something like: >
>     Feature-Caps: *;g.uri=3D"sip:foo@example.com";audio
>     Feature-Caps: *;g.uri=3D"sip:bar@example.com";audio;video= ;isfocus
>     Feature-Caps: *;g.uri=3D"sip:baz@example.com";text
>
> (I'm making up g.uri for the example.)
>
> And then presumably somebody on the signaling path will "shop&quo= t; in the feature caps for the capabilities it wants, and then send a reque= st to that URI, with the expectation that the UA responding will have those= capabilities.
>
>> The semantics should be no different than those of  the corre= sponding existing media  feature tag if it is present in the Contact h= eader.
>
> Note that 6809 says:
>
>      When a SIP entity receives a SIP request= , or response, that contains
>      one or more Feature-Caps header fields, = the feature-capability
>      indicators in the header field inform th= e entity about the features
>      and capabilities supported by entities i= n the SIP message signaling
>      path.  The procedure by which featu= res and capabilities are invoked
>      are outside the scope of this specificat= ion and MUST be described by
>      individual feature-capability indicator = specifications.
>
>      A Feature-Caps header field value cannot= convey the address of the
>      SIP entity that inserted the Feature-Cap= s header field.  If
>      additional data about a supported featur= e needs to be conveyed, such
>      as the address of the SIP entity that in= dicated support of the
>      feature, then the feature definition nee= ds to define a way to convey
>      that information as a value of the assoc= iated feature-capability
>      indicator.
>
> This was discussed at length while that RFC was under consideration. Y= et the definitions of the tags in *this* draft don't specify that.
>
>> The registration templates currently reference the RFC 3840 and th= e other RFCs that define the other media feature tags that correspond to th= ese feature capability indicators.
>
> And those definitions were written to be understood in the context of = 3840/3841. They make sense in that context, but not in *this* context.
>
>        Thanks,
>        Paul
>
>> But if more explicit detail is required then I can add some more t= ext  or alternatively remove the less important ones if they are going= to become rat holes. The ones I regard as really important and urgent are = sip.methods, sip.extensions and sip.events the meaning of which I think should be quite clear.
>>
>> Andrew
>>
>> ----- Original Message -----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com
>> <Gonzalo.Camarillo@ericsson.com>
>> Cc: rlb@ipv.sx= <rlb@ipv.sx>; adam@nostrum.com = <adam@nostrum.com<= /a>>;
>> christer.holmberg@ericsson.com <christer.holmberg@ericsson.com>; >> ma= ry.ietf.barnes@gmail.com <mary.ietf.barnes@gmail.com>; Paul Kyzivat
>> <pky= zivat@alum.mit.edu>
>> Subject: Re: New sipcore draft submission
>> draft-allen-sipcore-sip-tree-cap-indicators
>>
>> On 10/24/13 4:07 PM, Andrew Allen wrote:
>>>
>>> Paul
>>>
>>> Ok
>>>
>>> So we are basically where I thought we were at when I submitte= d the draft.
>>>
>>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone= else who indicates interest) can have some offline discussion in Vancouver= on whether and how to progress this.
>>
>> As I indicated again on the sipcore list, I found the that the dra= ft
>> didn't explain nearly enough to allow meaningful use of these.
>> I know you replied, and I will continue the conversation there. >> But I will be opposed to these until and unless the draft (and not= ably
>> the descriptions of the tags) are clear about how one could figure= out
>> what can do in the presence of the tags that one couldn't do witho= ut
>> them. AND, that the behavior that suggests doesn't "break&quo= t; sip. (E.g.,
>> by advocating a new and incompatible way to do something.)
>>
>> We can continue this on the sipcore list.
>>
>>       Thanks,
>>       Paul
>>
>>> Andrew
>>>
>>> ----- Original Message -----
>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Tim= e
>>> To: Andrew Allen; Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.co= m>
>>> Cc: Richard Barnes (rlb@ipv.sx) <r= lb@ipv.sx>; Adam Roach
>>> (adam@no= strum.com) <ad= am@nostrum.com>; Christer Holmberg
>>> (christer.holmberg@ericsson.com) <christer.holmberg@ericsson.com&= gt;;
>>> Mary Barnes (mary.ietf.barnes@gmail.com) <mary.ietf.barnes@gmail.com><= br> >>> Subject: Re: New sipcore draft submission
>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>
>>> On 10/24/13 2:17 PM, Andrew Allen wrote:
>>>> Paul
>>>>
>>>> That is fine. Although Mary in her reply to me seemed to i= ndicate maybe there was a possibility to use some of the DISPATCH spare tim= e for a SIPCORE session for this. Is that a possibility?
>>>>
>>>> I already replied to your post
>>>
>>> I discussed that with Adam. We decided we can't set a preceden= t to
>>> spin up a session to discuss a draft that hasn't had substanti= al
>>> (any) list discussion.
>>>
>>> But list discussion is always welcome.
>>>
>>>      Sorry,
>>>      Paul
>>>
>>>> Andrew
>>>>
>>>> -----Original Message-----
>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>> Sent: Thursday, October 24, 2013 1:31 PM
>>>> To: Andrew Allen; Gonzalo Camarillo
>>>> Cc: Richard Barnes (rlb@ipv.sx); Adam Roach (adam@nostrum.com);
>>>> Christer Holmberg (christer.holmberg@ericsson.com)
>>>> Subject: Re: New sipcore draft submission
>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>
>>>> Andrew,
>>>>
>>>> I spoke with Mary about it, and we concluded that dispatch= isn't right for this. (In addition to being clearly sipcore, it didn't mee= t the deadline for dispatch.) I was wrong to encourage you that way.
>>>>
>>>> So no official live discussion in Vancouver. (But informal=
>>>> discussion
>>>> fine.)
>>>>
>>>> I'll resend my private comments to the sipcore list to kic= kstart some discussion there.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>> On 10/24/13 1:01 PM, Andrew Allen wrote:
>>>>> I just emailed Mary asking for agenda time. Should I c= ancel that request?
>>>>>
>>>>> -----Original Message-----
>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.co= m]
>>>>> Sent: Thursday, October 24, 2013 1:00 PM
>>>>> To: Paul Kyzivat
>>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx); Adam Roach
>>>>> (adam@nostrum.com); Christer Holmberg
>>>>> (christer.holmberg@ericsson.com)
>>>>> Subject: Re: New sipcore draft submission
>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>
>>>>> Hi Paul,
>>>>>
>>>>> given that you think this belongs to SIPCORE, I do not= see the need to run it through DISPATCH. Please, start technical discussio= ns on the draft on the SIPCORE list.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Gonzalo
>>>>>
>>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote:
>>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote:
>>>>>>> Paul
>>>>>>>
>>>>>>> Thanks for reviewing the draft already and giv= ing me early feedback.
>>>>>>>
>>>>>>> My responses below inline (prepended with [AA)= .
>>>>>>>
>>>>>>> Can I ask the ADs to determine ASAP if this ne= eds to go to
>>>>>>> DISPATCH first or not. As outlined below my vi= ew is that it is
>>>>>>> unnecessary for every little thing to go to DI= SPATCH as this just
>>>>>>> creates additional delay and overhead. If it i= s to be discussed
>>>>>>> in DISPATCH then I definitely would want agend= a time atIETF#88 for this.
>>>>>>
>>>>>> Having now seen Andrew's responses to my initial q= uestions, I
>>>>>> think this
>>>>>> *needs* to be carefully considered by sipcore. IMO= this has the
>>>>>> potential to create a dialect of sip that is incom= patible with
>>>>>> normal usage. (Maybe IMS has already done that. Bu= t this will make
>>>>>> it
>>>>>> worse.)
>>>>>>
>>>>>> But if there is a desire to discuss it publicly in= Vancouver then
>>>>>> dispatch is the opportunity and so some discussion= on the dispatch
>>>>>> list in advance of that would be appropriate.
>>>>>>
>>>>>> I'll defer to the ADs on this.
>>>>>>
>>>>>> More inline.
>>>>>>
>>>>>>> Andrew
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM
>>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx); Gonzalo Camarillo
>>>>>>> (Gonzalo.Camarillo@ericsson.com); Adam Roach (adam@nostrum.com) >>>>>>> Subject: Re: New sipcore draft submission
>>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>>
>>>>>>> Andrew,
>>>>>>>
>>>>>>> On a legalistic note, its questionable to me w= hether this kind of
>>>>>>> action falls within the scope of sipcore. OTOH= , among existing
>>>>>>> wgs, sipcore is probably the best suited to di= scuss the proposal.
>>>>>>> We could take it to DISPATCH. I think DISPATCH= has extra time in
>>>>>>> its agenda for Vancouver, so that might be one= option for you.
>>>>>>> But then I don't know where dispatch would dis= patch it. It may be
>>>>>>> that AD sponsored is the best way to go.
>>>>>>>
>>>>>>> [AA] It seemed to me that sipcore was the righ= t place. This draft
>>>>>>> registers feature-capability indicators in a r= egistry that was
>>>>>>> created by a sipcore RFC (RFC 6809). You could= in my view make an
>>>>>>> argument that this should even have been done = as part of RFC 6809.
>>>>>>
>>>>>> If this was just a matter of registering some new = feature caps
>>>>>> that were not controversial, then I don't think si= pcore needs to be involved.
>>>>>>
>>>>>> But as I mentioned above, I do consider these cont= roversial.
>>>>>>
>>>>>>> Discussing it now on the dispatch list would b= e a good start
>>>>>>> toward discussing it at the dispatch session.<= br> >>>>>>>
>>>>>>> [AA] Can I ask the ADs to determine if this ne= eds to go to
>>>>>>> DISPATCH first or not. My view is that it is u= nnecessary for
>>>>>>> every little thing to go to DISPATCH as this j= ust creates additional delay and overhead.
>>>>>>> This just registers some indicators in an exis= ting IANA registry
>>>>>>> and is not (or should not be IMHO) a major pro= ject.
>>>>>>
>>>>>> To me this is a matter of whether you want to be o= pportunistic.
>>>>>> If this went to dispatch I would now recommend tha= t it be
>>>>>> dispatched to sipcore. So its a matter of whether = you want to talk
>>>>>> about it in the dispatch meeting.
>>>>>>
>>>>>>> Regarding substance, this draft troubles me. I= t takes
>>>>>>> feature-caps in exactly the direction that I f= ound most
>>>>>>> concerning about the mechanism in the first pl= ace.
>>>>>>>
>>>>>>> Your draft partitions the existing media featu= re tags into two
>>>>>>> sets
>>>>>>> - those that would be useful as feature-capabi= lity-indicators,
>>>>>>> and those that aren't. But I see no explanatio= n of the criteria
>>>>>>> used to make this distinction, nor can I think= of one.
>>>>>>>
>>>>>>> [AA] I based this decision on the following cr= iteria: If a
>>>>>>> feature tag was potentially at all useful for = an intermediary to
>>>>>>> indicate it then include it in the registry. T= he ones not
>>>>>>> included are either directly associated with t= he user
>>>>>>> (intermediaries are not  directly associa= ted with the user) or
>>>>>>> would only ever have one value (e.g automata).=   I am not sure
>>>>>>> that every feature-capability indicator propos= ed to be registered
>>>>>>> is actually useful but then I don't think ever= y media feature tag
>>>>>>> registered by RFC 3840 is either (I doubt very= much if there are
>>>>>>> implementation using the sip.application or si= p.control feature
>>>>>>> tags). I don't think RFC 3840 goes into a lot = of details
>>>>>>> justifying of ever registered media feature ta= g and specifying
>>>>>>> the details of how they would be used either.&= nbsp; I am willing to
>>>>>>> remove any feature-capability indicators that = are controversial except that I think we definitely need sip.extensions, si= p.methods and sip.events.
>>>>>>> There is a significant overhead to writing an<= br> >>>>>> d progressing internet drafts so my view is lets r= egister all that
>>>>>> might be remotely useful in the same document.
>>>>>>
>>>>>> The judgement of "useful" is reasonable.= But I still can't discern
>>>>>> what the use is from the iana registration descrip= tions.
>>>>>>
>>>>>>> For the ones that you have requested feature c= apability
>>>>>>> indicators, I cannot figure out what using the= m would mean. For
>>>>>>> example, when I see isFocus on a Contact heade= r I know I am in a
>>>>>>> conference, and that I can subscribe to the co= nference event
>>>>>>> package at the contact URI. If I see isFocus i= n a Feature-Caps header, what does it mean?
>>>>>>> What can I do once I know this?
>>>>>>>
>>>>>>> Section 5.14 of this draft says:
>>>>>>>
>>>>>>>        = ;      This Feature-capability indicator indicates= that the intermediary
>>>>>>>        = ;      is a conference server, also known as a foc= us, and is capable of
>>>>>>>        = ;      mixing together the media for all calls to = the same URI.
>>>>>>> ...
>>>>>>>        = ;         Examples of typical use: = A conference bridge
>>>>>>> indicating that it
>>>>>>>        = ;         is a conference bridge an= d is capable of acting as
>>>>>>> a conference
>>>>>>>        = ;         focus for this session. >>>>>>>
>>>>>>> [AA] the presence of isfocus in a Feature-Caps= header field means
>>>>>>> that a UA can initiate a conference by sending= a REFER request to
>>>>>>> the intermediary to invite another user and cr= eate a multi user
>>>>>>> conference from the 1-1 session.
>>>>>>>
>>>>>>> Note that Feature-Caps doesn't indicate which = entity has this
>>>>>>> capability, only that something does. And sinc= e this would
>>>>>>> presumably only be used if it wasn't the UAC o= f the request,
>>>>>>> sending a subscribe to the contact address of = the UAC wouldn't make sense.
>>>>>>>
>>>>>>> [AA] Yes the GRUU of the intermediary would be= needed but I
>>>>>>> consider this application specific and so this= would be included
>>>>>>> in a feature tag registered in the global tree= as stated in the
>>>>>>> draft "RFC 6809 [1] provides that address= es of intermediaries can
>>>>>>> be communicated as a value of an associated fe= ature-capability
>>>>>>> indicator so it would be appropriate to define= feature capability
>>>>>>> indicators as part of the global tree to commu= nicate the GRUU of
>>>>>>> the intermediary and hence this is outside the= scope of this
>>>>>>> document."  - RFC 6809 states "= If additional data about a
>>>>>>> supported feature needs to be conveyed, such a= s the address of
>>>>>>> the SIP entity that indicated support of the f= eature, then the
>>>>>>> feature definition needs to define a way to co= nvey that
>>>>>>> information as a value of the associated featu= re-capability
>>>>>>> indicator." However I think the SIP speci= fic capability
>>>>>>> indicators such as methods, extensions and eve= nts should
>>>>>>> appropriately be registered in the SIP tree no= t as proprietary
>>>>>>> indicator
>>>>>> s in the global tree.
>>>>>>
>>>>>> So you have defined a sip tree feature tag that is= only useful in
>>>>>> conjunction with another feature tag from the glob= al tree.
>>>>>> And the description of this feature tag doesn't ev= en mention that.
>>>>>>
>>>>>> And this all implies a completely non-standard cal= l model - doing
>>>>>> conferencing in a way inconsistent with RFC 4579.<= br> >>>>>>
>>>>>> ISTM that if 4579 doesn't work for you then you sh= ould be back
>>>>>> proposing extensions/revisions to it.
>>>>>>
>>>>>>> If there is a conference bridge in the signali= ng path, then I
>>>>>>> would expect it to be the UAC.
>>>>>>>
>>>>>>> [AA] Although a "standard" way to in= voke a conference is to send
>>>>>>> a REFER to the other UAs to invite them to the= conference focus,
>>>>>>> in many deployments a scenario exists where a = call involves an
>>>>>>> IP-PBX or Telephony Application Server (TAS) t= hat can act as a
>>>>>>> focus for the conference. A participant of a c= all can then create
>>>>>>> a conference by sending a REFER request in dia= log to the IP-PBX
>>>>>>> or TAS to use 3PCC to Invite other users to a = conference. Reasons for this are 1.
>>>>>>> Not all UAs support REFER,
>>>>>>
>>>>>> So you are saying the intermediary isn't a focus (= its a B2BUA),
>>>>>> but it *could become* a focus.
>>>>>>
>>>>>> The concept that a dialog may contain intermediari= es that can be
>>>>>> addressed to do stuff is not part of any sip stand= ard that I am
>>>>>> aware of. I don't care too much as long as the &qu= ot;stuff" is
>>>>>> application stuff that is outside the scope of sip= . But when it is
>>>>>> alternative ways to do stuff that sip supports, th= en I get upset.
>>>>>>
>>>>>>> 2. Many SBCs reject REFER requests going outsi= de domains because
>>>>>>> of the potential for charging fraud (referring= to a premium rate
>>>>>>> number
>>>>>>> etc) 3. A User receiving a REFER and then usin= g an INVITE to join
>>>>>>> the conference may be charged for initiating&n= bsp; the call when the
>>>>>>> scenario is that the initiator of the conferen= ce should be charged.
>>>>>>> 4. No need to obtain and distribute conference= URIs.
>>>>>>> Problem is how to achieve the same behavior wi= thout dialog reuse
>>>>>>> which has been deprecated by RFC 6665?
>>>>>>
>>>>>> Then maybe the problem needs to be brought up, and= a standard
>>>>>> solution proposed, rather than simply enabling a p= roprietary mechanism.
>>>>>>
>>>>>>> As another example, consider section 5.1:
>>>>>>>
>>>>>>>        = ;      Descrition:
>>>>>>>        = ;      This Feature-capability indicator indicates= that the intermediary
>>>>>>>        = ;      supports audio as a streaming media type. >>>>>>> ...
>>>>>>>        = ;         Examples of typical use: = An IP PBX indicating that it is
>>>>>>>        = ;         capable of accepting and = initiating sessions with audio as a
>>>>>>>        = ;         streaming media type.
>>>>>>>
>>>>>>> This definition *implies* an assumption about = the working
>>>>>>> environment
>>>>>>> - one that AFAIK is new. It implies that you n= eed to know that
>>>>>>> intermediaries support a media type before you= can use it. Would
>>>>>>> it be bad if there were no intermediaries, and= so none indicated this?
>>>>>>> What if some intermediary *did* indicate suppo= rt, but some other
>>>>>>> doesn't, but doesn't indicate that it doesn't?=
>>>>>>>
>>>>>>> Bottom line: how would the presence or absence= of this feature
>>>>>>> tag affect subsequent usage?
>>>>>>>
>>>>>>> [AA] The absence of the streaming types does n= ot indicate that
>>>>>>> the intermediary does not support the media ty= pe and SDP offer
>>>>>>> answer will ultimately determine what can or c= annot be used if
>>>>>>> another session is initiated involving the int= ermediary. However
>>>>>>> the presence of the media type in a Feature-ca= ps header field
>>>>>>> does explictly confirm that the intermediary d= oes support the
>>>>>>> media type and in the scenario where a UA has = a choice of
>>>>>>> multiple intermediaries it could use for a con= ference it might
>>>>>>> choose to use the one that explicitly indicate= s it supports the media types the UA wants to use.
>>>>>>
>>>>>> So the UA will be able to discover that *some* int= ermediary
>>>>>> supports media it is interested in. And it can tel= l that *some*
>>>>>> intermediary says it is a focus. It doesn't know i= f they are the same intermediary.
>>>>>>
>>>>>> And then via some other feature tag it obtains the= URI of *some*
>>>>>> intermediary on the signaling path. Or maybe it ge= ts more than one
>>>>>> of these.
>>>>>>
>>>>>> It then makes a leap of faith and conflates all th= ose things, to
>>>>>> determine that the URI identifies a focus that sup= ports this media type.
>>>>>>
>>>>>> Even then, exactly what does that mean? It may or = may not mean
>>>>>> that it supports mixing that media type in a confe= rence.
>>>>>>
>>>>>>> As I stated already I don't care that much abo= ut these streaming
>>>>>>> media types.
>>>>>>
>>>>>>> I could go on, but this is enough for now.
>>>>>>>
>>>>>>> [AA] My motivation for this is that currently = 3GPP are updating
>>>>>>> their specifications to use RFC 6665 instead o= f RFC 3265.
>>>>>>
>>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE = and REFER with
>>>>>>> intermediaries accepting the REFER or SUBSCRIB= E request rather
>>>>>>> than forwarding it all the way to the remote U= A.
>>>>>>
>>>>>> And 6665 deprecates dial reuse in most of those ca= ses.
>>>>>> Without dialog reuse, the intermediaries don't get= an opportunity
>>>>>> to intercept those.
>>>>>>
>>>>>>> In order to know that an intermediary supports= the target dialog
>>>>>>> mechanism  needed for a REFER request sen= t outside the dialog to
>>>>>>> work we need sip.extensions as a feature-capab= ility indicator. In
>>>>>>> order to know that the needed event package is= supported by the
>>>>>>> intermediary so we can SUBSCROBE outside the d= ialog to an
>>>>>>> intermediary we need sip.events as a feature-c= apability indicator.
>>>>>>
>>>>>> Then I think you should be back here with a proble= m statement and
>>>>>> a request for how to get sip to solve it.
>>>>>>
>>>>>> And you should touch base with Christer on this. H= e may have a
>>>>>> different opinion on the relevance of feature-caps= as a solution.
>>>>>>
>>>>>>        &nb= sp; Thanks,
>>>>>>        &nb= sp; Paul
>>>>>>
>>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote:
>>>>>>>> Adam, Paul, Richard, Gonzalo
>>>>>>>>
>>>>>>>> I have submitted a new draft to sipcore&nb= sp; to register a number of
>>>>>>>> feature capability indicators in the SIP t= ree (based upon some
>>>>>>>> of the existing SIP media feature tags). T= he draft can be found at:
>>>>>>>>
>>>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00.<= br> >>>>>>>> txt
>>>>>>>>
>>>>>>>> Since there will not be a sipcore session = at IETF#88  can we
>>>>>>>> have an offline discussion on how to progr= ess this draft (which
>>>>>>>> hopefully is fairly straightforward as it = just registers feature
>>>>>>>> capabilities indicators with IANA). I woul= dn't want to have to
>>>>>>>> wait until March next year for a decision = on progressing this.
>>>>>>>>
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>> ------------------------------------------= ----------------------
>>>>>>>> ---
>>>>>>>> -
>>>>>>>> - This transmission (including any attachm= ents) may contain
>>>>>>>> confidential information, privileged mater= ial (including
>>>>>>>> material protected by the solicitor-client= or other applicable
>>>>>>>> privileges), or constitute non-public info= rmation. Any use of
>>>>>>>> this information by anyone other than the = intended recipient is
>>>>>>>> prohibited. If you have received this tran= smission in error,
>>>>>>>> please immediately reply to the sender and= delete this
>>>>>>>> information from your system. Use, dissemi= nation, distribution,
>>>>>>>> or reproduction of this transmission by un= intended recipients is not authorized and may be unlawful.
>>>>>>>
>>>>>>> ----------------------------------------------= -------------------
>>>>>>> ---
>>>>>>> - This transmission (including any attachments= ) may contain
>>>>>>> confidential information, privileged material = (including material
>>>>>>> protected by the solicitor-client or other app= licable
>>>>>>> privileges), or constitute non-public informat= ion. Any use of
>>>>>>> this information by anyone other than the inte= nded recipient is
>>>>>>> prohibited. If you have received this transmis= sion in error,
>>>>>>> please immediately reply to the sender and del= ete this
>>>>>>> information from your system. Use, disseminati= on, distribution,
>>>>>>> or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------= -------------
>>>>> -- This transmission (including any attachments) may c= ontain
>>>>> confidential information, privileged material (includi= ng material protected by the solicitor-client or other applicable privilege= s), or constitute non-public information. Any use of this information by an= yone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, disseminat= ion, distribution, or reproduction of this transmission by unintended recip= ients is not authorized and may be unlawful.
>>>>>
>>>>>
>>>>
>>>> ----------------------------------------------------------= ----------
>>>> - This transmission (including any attachments) may contai= n
>>>> confidential information, privileged material (including m= aterial protected by the solicitor-client or other applicable privileges), = or constitute non-public information. Any use of this information by anyone= other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, disseminat= ion, distribution, or reproduction of this transmission by unintended recip= ients is not authorized and may be unlawful.
>>>>
>>>>
>>>
>>> --------------------------------------------------------------= -------
>>> This transmission (including any attachments) may contain conf= idential information, privileged material (including material protected by = the solicitor-client or other applicable privileges), or constitute non-pub= lic information. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>>
>>>
>>
>> ------------------------------------------------------------------= ---
>> This transmission (including any attachments) may contain confiden= tial information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute non-public = information. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>>
>>
>
> ---------------------------------------------------------------------<= br> > This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the soli= citor-client or other applicable privileges), or constitute non-public info= rmation. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>
>

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
--_000_7594FB04B1934943A5C02806D1A2204B1C4F713BESESSMB209erics_-- From aallen@blackberry.com Fri Oct 25 12:19:55 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC1711E819A for ; Fri, 25 Oct 2013 12:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAso13lMqyzu for ; Fri, 25 Oct 2013 12:19:50 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 325E111E810C for ; Fri, 25 Oct 2013 12:19:44 -0700 (PDT) Received: from xct105ads.rim.net ([10.67.111.46]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 25 Oct 2013 15:19:43 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.03.0123.003; Fri, 25 Oct 2013 14:19:42 -0500 From: Andrew Allen To: "christer.holmberg@ericsson.com" , "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0bKxmuu2OBPqMUmxvta8f/E6B5oFxJ0ggABXyYD//66E2g== Date: Fri, 25 Oct 2013 19:19:42 +0000 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4F713B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338E3CD6EXMB104ADSrimnet_" MIME-Version: 1.0 Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:19:55 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338E3CD6EXMB104ADSrimnet_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 DQpBZ3JlZWQNCg0KDQpGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbV0NClNlbnQ6IEZyaWRheSwgT2N0b2JlciAyNSwgMjAxMyAwMjox MSBQTSBDZW50cmFsIFN0YW5kYXJkIFRpbWUNClRvOiBBbmRyZXcgQWxsZW47IFBhdWwgS3l6aXZh dCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PjsgU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NClN1 YmplY3Q6IFJFOiBbc2lwY29yZV0gTmV3IHNpcGNvcmUgZHJhZnQgc3VibWlzc2lvbiBkcmFmdC1h bGxlbi1zaXBjb3JlLXNpcC10cmVlLWNhcC1pbmRpY2F0b3JzDQoNCg0KSGksDQoNCj5JZiB0aGUg c2VtYW50aWMgb2YgZy54IGlzIGRlZmluZWQgYXMgdGhlIHN1cHBvcnQgZm9yIHRoZSBzZXNzaW9u IHRyYW5zZmVyIGNhcGFiaWxpdHkgYW5kIHRoZSBVUkkgYXQgdGhlIGVudGl0eSBpbmNsdWRpbmcg aXQgZm9yIHNlbmRpbmcgcmVxdWVzdCB0byBpbnZva2UNCj50aGUgc2Vzc2lvbiB0cmFuc2ZlciAg dGhlbiB0aGUgc2lwIG1ldGhvZHMgYW5kIHNpcCBleHRlbnNpb25zIGFsc28gaW5jbHVkZWQgaW4g dGhlIEZlYXR1cmUtQ2FwcyBoZWFkZXIgZmllbGQgYWxzbyBhcHBseSB0byB0aGUgVVJJIGZvciBz ZXNzaW9uIHRyYW5zZmVyLg0KDQpFdmVuIGlmIHRoZSBzZW1hbnRpYyBvZiBnLnggZXhwbGljaXRs eSBzYXlzIHRoYXQgdGhlIGFkZHJlc3MgcG9pbnRzIHRvIHRoZSBzYW1lIGVudGl0eSB0aGF0IGlu ZGljYXRlcyBzdXBwb3J0IG9mIHRoZSBmZWF0dXJlLCBJIHN0aWxsIHRoaW5rIHRoZSBnLnggRkNJ IHNwZWNpZmljYXRpb24gc2hvdWxkIGRlc2NyaWJlIGhvdyBnLnggaXMgdXNlZCB0b2dldGhlciB3 aXRoIG90aGVyIEZDSXMgKGUuZy4gK3NpcC5tZXRob2RzKS4NCg0KVGhhdCB3aWxsIGhlbHAgaW1w bGVtZW50b3JzIHRvIGRldGVybWluZSB3aGV0aGVyIHRoZXkgY2FuIGluY2x1ZGUgZy55IGluIHRo ZSBzYW1lIEZlYXR1cmUtQ2FwcyBoZWFkZXIgZmllbGQgYXMgZy54IG9yIG5vdCwgaWYgZy55IGFs c28gdXNlcyArc2lwLm1ldGhvZHMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTog Q2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21d DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMjUsIDIwMTMgMjo0NyBQTQ0KVG86IFBhdWwgS3l6aXZh dDsgQW5kcmV3IEFsbGVuOyBTSVBDT1JFDQpTdWJqZWN0OiBSRTogW3NpcGNvcmVdIE5ldyBzaXBj b3JlIGRyYWZ0IHN1Ym1pc3Npb24gZHJhZnQtYWxsZW4tc2lwY29yZS1zaXAtdHJlZS1jYXAtaW5k aWNhdG9ycw0KDQoNCkhpLA0KDQoNCg0KPj4gVGhlIG5leHQgcmV2aXNpb25zIHdpbGwgY29udGFp biBtb3JlIGRldGFpbHMgb24gd2hhdCBlYWNoIEZDSSAoYXMgQ2hyaXN0ZXIgbm93IGNhbGxzIHRo ZW0gbWVhbnMpLg0KPj4NCj4+IElmIHNvbWUgYXJlIG5vdCB3ZWxsIHVuZGVyc3Rvb2QgSSB3aWxs IHJlbW92ZSB0aGVtIGZyb20gdGhlIGRyYWZ0IChpLmUuIGRyb3AgIHRoZSByYXQgaG9sZXMpDQo+ Pg0KPj4gSSB0aGluayBteSBlbWFpbCBleGNoYW5nZSB3aXRoIENocmlzdGVyIGNsYXJpZmllcyB0 aGUgb3RoZXIgcG9pbnRzLg0KPj4NCj4+IERvZXMgdGhpcyByZXByZXNlbnQgaW4gcHJpbmNpcGxl IGEgd2F5IGZvcndhcmQ/DQo+DQo+IE1heWJlLiBXZSdsbCBoYXZlIHRvIHNlZSBob3cgaXQgZ29l cy4NCj4NCj4gVGhlIGNoYWxsZW5nZSBpcywgSSB0aGluaywgdGhhdCB5b3Ugd2FudCB0byBicmlu ZyBpbiBhIGJ1bmNoIG9mIHRoZSAzODQwDQo+IGZlYXR1cmUgdGFncywgYW5kIGhhdmUgdGhlbSBt ZWFuIHNvbWV0aGluZyBha2luIHRvIHdoYXQgdGhleSBkbyBhcw0KPiBmZWF0dXJlIHRhZ3Mgd2hl biB1c2VkIGFzIEZDSXMuIEJ1dCB0aGVyZSBuZWVkcyB0byBiZSBzb21lIHdheSB0bw0KPiBkZXNj cmliZSB3aGF0ICplYWNoKiBvbmUgbWVhbnMuIEl0J3Mgbm90IGltbWVkaWF0ZWx5IGNsZWFyIHRv IG1lIGhvdyB0bw0KPiBkbyB0aGF0Lg0KDQpBcyBJIHNhaWQgaW4gYW5vdGhlciByZXBseSwgSSB0 aGluayB0aGF0IHRoZSBGQ0lzIHRoYXQgdXNlIHRoZSArc2lwLm1ldGhvZCBldGMgRkNJcyBuZWVk IHRvIGRlc2NyaWJlIGhvdyB0aGV5IGFyZSB1c2VkIGluIGNvbmp1bmN0aW9uLg0KDQoNCg0KRXhh bXBsZToNCg0KDQoNCkZlYXR1cmUtQ2FwczogKjsrZy54OytzaXAubWV0aG9kcz0iSU5WSVRFIg0K DQpGZWF0dXJlLUNhcHM6ICo7K2cueTsrc2lwLm1ldGhvZHM9IklOVklURSINCg0KDQoNClRoZSBG Q0kgc3BlY2lmaWNhdGlvbnMgZm9yICtnLnggYW5kICtnLnkgbmVlZCB0byBkZXNjcmliZSBob3cg dGhleSBhcmUgdXNlZCB0b2dldGhlciB3aXRoICtzaXAubWV0aG9kcywgaWYgdGhlcmUgaXMgYSBy ZWxhdGlvbnNoaXAuDQoNCg0KDQpPdGhlcndpc2UgK3NpcC5tZXRob2RzIG9ubHkgbWVhbnMgdGhh dCB0aGUgZW50aXR5IHRoYXQgaW5zZXJ0ZWQgdGhlIEZDSXMgc3VwcG9ydCAiSU5WSVRFIi4NCg0K DQoNClJlZ2FyZHMsDQoNCg0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5 eml2YXRAYWx1bS5taXQuZWR1XQ0KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjUsIDIwMTMgMTA6 MDYgQU0NCj4gVG86IEFuZHJldyBBbGxlbjsgR29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29t PG1haWx0bzpHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+DQo+IENjOiBybGJAaXB2LnN4 PG1haWx0bzpybGJAaXB2LnN4PjsgYWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVt LmNvbT47IGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPjsgbWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb208bWFpbHRvOm1h cnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPg0KPiBTdWJqZWN0OiBSZTogTmV3IHNpcGNvcmUgZHJh ZnQgc3VibWlzc2lvbiBkcmFmdC1hbGxlbi1zaXBjb3JlLXNpcC10cmVlLWNhcC1pbmRpY2F0b3Jz DQo+DQo+IEFuZHJldywNCj4NCj4gKEkgc2VlIHRoaXMgaXMgc3RpbGwgb24gdGhlIHByaXZhdGUg dGhyZWFkLiBJJ2xsIHJlcGx5IGhlcmUsIGJ1dCB0aGlzIGV4Y2hhbmdlIHNob3VsZCBwcm9iYWJs eSBiZSByZXBvc3RlZCB0byB0aGUgc2lwY29yZSBsaXN0IGFzIHBhcnQgb2YgdGhlIHB1YmxpYyBk aXNjdXNzaW9uIG9mIHRoZSBkcmFmdC4pDQo+DQo+IE9uIDEwLzI0LzEzIDEwOjQxIFBNLCBBbmRy ZXcgQWxsZW4gd3JvdGU6DQo+Pg0KPj4gUGF1bA0KPj4NCj4+IEkgYW0gaGFwcHkgdG8gZG8gYSBy ZXZpc2lvbiB3aXRoIG1vcmUgZGV0YWlscyBvbiB0aGUgc2VtYW50aWNzIG9mIHRoZSBjYXBhYmls aXR5IGluZGljYXRvcnMuIEhvd2V2ZXIgSSBkb24ndCB0aGluayBpdCBzaG91bGQgYmUgaGVsZCB0 byBhIHZlcnkgbXVjaCBoaWdoZXIgYmFyIHRoYW4gdGhlIGRldGFpbHMgaW4gUkZDIDM4NDAgYW5k IHRoZSBvdGhlciBtZWRpYSBmZWF0dXJlIHRhZyBSRkNzIHJlZ2FyZGluZyB0aGUgbWVhbmluZyBv ZiB0aG9zZSB0YWdzLg0KPg0KPiBLZWVwIGluIG1pbmQgdGhhdCB0aGUgZHJpdmluZyBmb3JjZSBm b3IgdGhlIGRlZmluaXRpb24gb2YgZmVhdHVyZSB0YWdzIGluIDM4NDAgd2FzIGluIHN1cHBvcnQg b2YgY2FsbGVycHJlZnMgKDM4NDEpLiBTbyB0aGUgY29udGV4dCBmb3IgdGhlIHVzZSBvZiBmZWF0 dXJlIHRhZ3Mgd2FzIHRoYXQgdGhleSB3b3VsZCBiZSBwbGFjZWQgb24gQ29udGFjdHMgaW4gUkVH SVNURVIgcmVxdWVzdHMuIFNvIHlvdSBjYW4gaW50ZXJwcmV0IHRoZSBkZWZpbml0aW9ucyBpbiB0 aGF0IGNvbnRleHQ6IHRoYXQgYSByZXF1ZXN0IHNlbnQgdG8gYW4gQU9SIHVzaW5nIGNhbGxlcnBy ZWZzIGNhbiBhZmZlY3QgdGhlIGNob2ljZSBvZiB3aGljaCBkZXZpY2UgdGhlIHJlcXVlc3QgZ29l cyB0byBhY2NvcmRpbmcgdG8gdGhlIGNhcGFiaWxpdGllcyBpdCB3YW50cy4gSW4gdGhhdCBjb250 ZXh0IGF1ZGlvLCB2aWRlbywgaXNmb2N1cyBhbGwgbWFrZSBzZW5zZS4NCj4NCj4gVGhlaXIgdXNl IG9uIENvbnRhY3RzIGluIGRpYWxvZ3Mgd2FzIGRlcml2YXRpdmUgdG8gdGhhdDogYmVjYXVzZSBj YWxsZXJwcmVmIHN1cHBvcnQgaXMgb3B0aW9uYWwsIHRoZXJlIGlzIG5vIGd1YXJhbnRlZSB0aGF0 IHRoZSBkZXZpY2UgeW91IHJlYWNoIHZpYSBjYWxsZXJwcmVmcyB3aWxsIGhhdmUgdGhlIGNhcGFi aWxpdGllcyB5b3UgcmVxdWVzdGVkLiBTbyB0aGUgdmFsdWVzIGluIHRoZSBjb250YWN0IGhlbHAg Y29uZmlybSB3aGF0IHlvdSBnb3QuDQo+DQo+IE9mIGNvdXJzZSB0aGV5IGhhdmUgc2luY2UgYmVl biB1c2VkIG90aGVyIHdheXMuIEFuZCB0aGUgZGVzY3JpcHRpb25zIG9mIHRoZW0gZG9uJ3QgbmVj ZXNzYXJpbHkgcmVmbGVjdCB0aGF0LiBJTU8gdGhhdCBpcyBhIGRlZmVjdCBkdWUgdG8gdGhlIGV2 b2x1dGlvbiBvZiB1c2UuDQo+DQo+IEknbSBsb29raW5nIGZvciB0aGUgc2FtZSBzb3J0IG9mIGNv bnRleHQgZm9yIHVzZSB3aXRoIHRoZSBmZWF0dXJlLWNhcHMuDQo+DQo+IEluIHByaXZhdGUgZGlz Y3Vzc2lvbiB5b3UgaW5kaWNhdGVkIHRvIG1lIHRoYXQgeW91IGV4cGVjdGVkIHRoZSBmZWF0dXJl IGNhcHMgdG8gYmUgZ3JvdXBlZCAtIHdpdGggb25lIG9mIHRoZW0gZ2l2aW5nIHRoZSBVUkkgb2Yg dGhlIGRldmljZSB0aGF0IHRoZSBvdGhlciB0YWdzIGFwcGx5IHRvLiBJIGd1ZXNzIHRoaXMgd291 bGQgZW5kIHVwIGxvb2tpbmcgc29tZXRoaW5nIGxpa2U6DQo+DQo+ICAgICBGZWF0dXJlLUNhcHM6 ICo7Zy51cmk9InNpcDpmb29AZXhhbXBsZS5jb20iO2F1ZGlvDQo+ICAgICBGZWF0dXJlLUNhcHM6 ICo7Zy51cmk9InNpcDpiYXJAZXhhbXBsZS5jb20iO2F1ZGlvO3ZpZGVvO2lzZm9jdXMNCj4gICAg IEZlYXR1cmUtQ2FwczogKjtnLnVyaT0ic2lwOmJhekBleGFtcGxlLmNvbSI7dGV4dA0KPg0KPiAo SSdtIG1ha2luZyB1cCBnLnVyaSBmb3IgdGhlIGV4YW1wbGUuKQ0KPg0KPiBBbmQgdGhlbiBwcmVz dW1hYmx5IHNvbWVib2R5IG9uIHRoZSBzaWduYWxpbmcgcGF0aCB3aWxsICJzaG9wIiBpbiB0aGUg ZmVhdHVyZSBjYXBzIGZvciB0aGUgY2FwYWJpbGl0aWVzIGl0IHdhbnRzLCBhbmQgdGhlbiBzZW5k IGEgcmVxdWVzdCB0byB0aGF0IFVSSSwgd2l0aCB0aGUgZXhwZWN0YXRpb24gdGhhdCB0aGUgVUEg cmVzcG9uZGluZyB3aWxsIGhhdmUgdGhvc2UgY2FwYWJpbGl0aWVzLg0KPg0KPj4gVGhlIHNlbWFu dGljcyBzaG91bGQgYmUgbm8gZGlmZmVyZW50IHRoYW4gdGhvc2Ugb2YgIHRoZSBjb3JyZXNwb25k aW5nIGV4aXN0aW5nIG1lZGlhICBmZWF0dXJlIHRhZyBpZiBpdCBpcyBwcmVzZW50IGluIHRoZSBD b250YWN0IGhlYWRlci4NCj4NCj4gTm90ZSB0aGF0IDY4MDkgc2F5czoNCj4NCj4gICAgICBXaGVu IGEgU0lQIGVudGl0eSByZWNlaXZlcyBhIFNJUCByZXF1ZXN0LCBvciByZXNwb25zZSwgdGhhdCBj b250YWlucw0KPiAgICAgIG9uZSBvciBtb3JlIEZlYXR1cmUtQ2FwcyBoZWFkZXIgZmllbGRzLCB0 aGUgZmVhdHVyZS1jYXBhYmlsaXR5DQo+ICAgICAgaW5kaWNhdG9ycyBpbiB0aGUgaGVhZGVyIGZp ZWxkIGluZm9ybSB0aGUgZW50aXR5IGFib3V0IHRoZSBmZWF0dXJlcw0KPiAgICAgIGFuZCBjYXBh YmlsaXRpZXMgc3VwcG9ydGVkIGJ5IGVudGl0aWVzIGluIHRoZSBTSVAgbWVzc2FnZSBzaWduYWxp bmcNCj4gICAgICBwYXRoLiAgVGhlIHByb2NlZHVyZSBieSB3aGljaCBmZWF0dXJlcyBhbmQgY2Fw YWJpbGl0aWVzIGFyZSBpbnZva2VkDQo+ICAgICAgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRo aXMgc3BlY2lmaWNhdGlvbiBhbmQgTVVTVCBiZSBkZXNjcmliZWQgYnkNCj4gICAgICBpbmRpdmlk dWFsIGZlYXR1cmUtY2FwYWJpbGl0eSBpbmRpY2F0b3Igc3BlY2lmaWNhdGlvbnMuDQo+DQo+ICAg ICAgQSBGZWF0dXJlLUNhcHMgaGVhZGVyIGZpZWxkIHZhbHVlIGNhbm5vdCBjb252ZXkgdGhlIGFk ZHJlc3Mgb2YgdGhlDQo+ICAgICAgU0lQIGVudGl0eSB0aGF0IGluc2VydGVkIHRoZSBGZWF0dXJl LUNhcHMgaGVhZGVyIGZpZWxkLiAgSWYNCj4gICAgICBhZGRpdGlvbmFsIGRhdGEgYWJvdXQgYSBz dXBwb3J0ZWQgZmVhdHVyZSBuZWVkcyB0byBiZSBjb252ZXllZCwgc3VjaA0KPiAgICAgIGFzIHRo ZSBhZGRyZXNzIG9mIHRoZSBTSVAgZW50aXR5IHRoYXQgaW5kaWNhdGVkIHN1cHBvcnQgb2YgdGhl DQo+ICAgICAgZmVhdHVyZSwgdGhlbiB0aGUgZmVhdHVyZSBkZWZpbml0aW9uIG5lZWRzIHRvIGRl ZmluZSBhIHdheSB0byBjb252ZXkNCj4gICAgICB0aGF0IGluZm9ybWF0aW9uIGFzIGEgdmFsdWUg b2YgdGhlIGFzc29jaWF0ZWQgZmVhdHVyZS1jYXBhYmlsaXR5DQo+ICAgICAgaW5kaWNhdG9yLg0K Pg0KPiBUaGlzIHdhcyBkaXNjdXNzZWQgYXQgbGVuZ3RoIHdoaWxlIHRoYXQgUkZDIHdhcyB1bmRl ciBjb25zaWRlcmF0aW9uLiBZZXQgdGhlIGRlZmluaXRpb25zIG9mIHRoZSB0YWdzIGluICp0aGlz KiBkcmFmdCBkb24ndCBzcGVjaWZ5IHRoYXQuDQo+DQo+PiBUaGUgcmVnaXN0cmF0aW9uIHRlbXBs YXRlcyBjdXJyZW50bHkgcmVmZXJlbmNlIHRoZSBSRkMgMzg0MCBhbmQgdGhlIG90aGVyIFJGQ3Mg dGhhdCBkZWZpbmUgdGhlIG90aGVyIG1lZGlhIGZlYXR1cmUgdGFncyB0aGF0IGNvcnJlc3BvbmQg dG8gdGhlc2UgZmVhdHVyZSBjYXBhYmlsaXR5IGluZGljYXRvcnMuDQo+DQo+IEFuZCB0aG9zZSBk ZWZpbml0aW9ucyB3ZXJlIHdyaXR0ZW4gdG8gYmUgdW5kZXJzdG9vZCBpbiB0aGUgY29udGV4dCBv ZiAzODQwLzM4NDEuIFRoZXkgbWFrZSBzZW5zZSBpbiB0aGF0IGNvbnRleHQsIGJ1dCBub3QgaW4g KnRoaXMqIGNvbnRleHQuDQo+DQo+ICAgICAgICBUaGFua3MsDQo+ICAgICAgICBQYXVsDQo+DQo+ PiBCdXQgaWYgbW9yZSBleHBsaWNpdCBkZXRhaWwgaXMgcmVxdWlyZWQgdGhlbiBJIGNhbiBhZGQg c29tZSBtb3JlIHRleHQgIG9yIGFsdGVybmF0aXZlbHkgcmVtb3ZlIHRoZSBsZXNzIGltcG9ydGFu dCBvbmVzIGlmIHRoZXkgYXJlIGdvaW5nIHRvIGJlY29tZSByYXQgaG9sZXMuIFRoZSBvbmVzIEkg cmVnYXJkIGFzIHJlYWxseSBpbXBvcnRhbnQgYW5kIHVyZ2VudCBhcmUgc2lwLm1ldGhvZHMsIHNp cC5leHRlbnNpb25zIGFuZCBzaXAuZXZlbnRzIHRoZSBtZWFuaW5nIG9mIHdoaWNoIEkgdGhpbmsg c2hvdWxkIGJlIHF1aXRlIGNsZWFyLg0KPj4NCj4+IEFuZHJldw0KPj4NCj4+IC0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0NCj4+IEZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0 QGFsdW0ubWl0LmVkdV0NCj4+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI0LCAyMDEzIDA0OjQ0 IFBNIENlbnRyYWwgU3RhbmRhcmQgVGltZQ0KPj4gVG86IEFuZHJldyBBbGxlbjsgR29uemFsby5D YW1hcmlsbG9AZXJpY3Nzb24uY29tPG1haWx0bzpHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5j b20+DQo+PiA8R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tPG1haWx0bzpHb256YWxvLkNh bWFyaWxsb0Blcmljc3Nvbi5jb20+Pg0KPj4gQ2M6IHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYu c3g+IDxybGJAaXB2LnN4PG1haWx0bzpybGJAaXB2LnN4Pj47IGFkYW1Abm9zdHJ1bS5jb208bWFp bHRvOmFkYW1Abm9zdHJ1bS5jb20+IDxhZGFtQG5vc3RydW0uY29tPG1haWx0bzphZGFtQG5vc3Ry dW0uY29tPj47DQo+PiBjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj47DQo+PiBtYXJ5LmlldGYu YmFybmVzQGdtYWlsLmNvbTxtYWlsdG86bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb20+IDxtYXJ5 LmlldGYuYmFybmVzQGdtYWlsLmNvbTxtYWlsdG86bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb20+ PjsgUGF1bCBLeXppdmF0DQo+PiA8cGt5eml2YXRAYWx1bS5taXQuZWR1PG1haWx0bzpwa3l6aXZh dEBhbHVtLm1pdC5lZHU+Pg0KPj4gU3ViamVjdDogUmU6IE5ldyBzaXBjb3JlIGRyYWZ0IHN1Ym1p c3Npb24NCj4+IGRyYWZ0LWFsbGVuLXNpcGNvcmUtc2lwLXRyZWUtY2FwLWluZGljYXRvcnMNCj4+ DQo+PiBPbiAxMC8yNC8xMyA0OjA3IFBNLCBBbmRyZXcgQWxsZW4gd3JvdGU6DQo+Pj4NCj4+PiBQ YXVsDQo+Pj4NCj4+PiBPaw0KPj4+DQo+Pj4gU28gd2UgYXJlIGJhc2ljYWxseSB3aGVyZSBJIHRo b3VnaHQgd2Ugd2VyZSBhdCB3aGVuIEkgc3VibWl0dGVkIHRoZSBkcmFmdC4NCj4+Pg0KPj4+IE1h eWJlIHlvdSwgQWRhbSwgR29uemFsbywgUmljaGFyZCwgQ2hyaXN0ZXIgYW5kIEkgKHBsdXMgYW55 b25lIGVsc2Ugd2hvIGluZGljYXRlcyBpbnRlcmVzdCkgY2FuIGhhdmUgc29tZSBvZmZsaW5lIGRp c2N1c3Npb24gaW4gVmFuY291dmVyIG9uIHdoZXRoZXIgYW5kIGhvdyB0byBwcm9ncmVzcyB0aGlz Lg0KPj4NCj4+IEFzIEkgaW5kaWNhdGVkIGFnYWluIG9uIHRoZSBzaXBjb3JlIGxpc3QsIEkgZm91 bmQgdGhlIHRoYXQgdGhlIGRyYWZ0DQo+PiBkaWRuJ3QgZXhwbGFpbiBuZWFybHkgZW5vdWdoIHRv IGFsbG93IG1lYW5pbmdmdWwgdXNlIG9mIHRoZXNlLg0KPj4gSSBrbm93IHlvdSByZXBsaWVkLCBh bmQgSSB3aWxsIGNvbnRpbnVlIHRoZSBjb252ZXJzYXRpb24gdGhlcmUuDQo+PiBCdXQgSSB3aWxs IGJlIG9wcG9zZWQgdG8gdGhlc2UgdW50aWwgYW5kIHVubGVzcyB0aGUgZHJhZnQgKGFuZCBub3Rh Ymx5DQo+PiB0aGUgZGVzY3JpcHRpb25zIG9mIHRoZSB0YWdzKSBhcmUgY2xlYXIgYWJvdXQgaG93 IG9uZSBjb3VsZCBmaWd1cmUgb3V0DQo+PiB3aGF0IGNhbiBkbyBpbiB0aGUgcHJlc2VuY2Ugb2Yg dGhlIHRhZ3MgdGhhdCBvbmUgY291bGRuJ3QgZG8gd2l0aG91dA0KPj4gdGhlbS4gQU5ELCB0aGF0 IHRoZSBiZWhhdmlvciB0aGF0IHN1Z2dlc3RzIGRvZXNuJ3QgImJyZWFrIiBzaXAuIChFLmcuLA0K Pj4gYnkgYWR2b2NhdGluZyBhIG5ldyBhbmQgaW5jb21wYXRpYmxlIHdheSB0byBkbyBzb21ldGhp bmcuKQ0KPj4NCj4+IFdlIGNhbiBjb250aW51ZSB0aGlzIG9uIHRoZSBzaXBjb3JlIGxpc3QuDQo+ Pg0KPj4gICAgICAgVGhhbmtzLA0KPj4gICAgICAgUGF1bA0KPj4NCj4+PiBBbmRyZXcNCj4+Pg0K Pj4+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4+PiBGcm9tOiBQYXVsIEt5eml2YXQg W21haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHVdDQo+Pj4gU2VudDogVGh1cnNkYXksIE9jdG9i ZXIgMjQsIDIwMTMgMDI6NTQgUE0gQ2VudHJhbCBTdGFuZGFyZCBUaW1lDQo+Pj4gVG86IEFuZHJl dyBBbGxlbjsgR29uemFsbyBDYW1hcmlsbG8gPEdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNv bTxtYWlsdG86R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tPj4NCj4+PiBDYzogUmljaGFy ZCBCYXJuZXMgKHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+KSA8cmxiQGlwdi5zeDxtYWls dG86cmxiQGlwdi5zeD4+OyBBZGFtIFJvYWNoDQo+Pj4gKGFkYW1Abm9zdHJ1bS5jb208bWFpbHRv OmFkYW1Abm9zdHJ1bS5jb20+KSA8YWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVt LmNvbT4+OyBDaHJpc3RlciBIb2xtYmVyZw0KPj4+IChjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4pIDxjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4+Ow0KPj4+IE1hcnkgQmFybmVzIChtYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbTxtYWlsdG86 bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb20+KSA8bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb208 bWFpbHRvOm1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPj4NCj4+PiBTdWJqZWN0OiBSZTogTmV3 IHNpcGNvcmUgZHJhZnQgc3VibWlzc2lvbg0KPj4+IGRyYWZ0LWFsbGVuLXNpcGNvcmUtc2lwLXRy ZWUtY2FwLWluZGljYXRvcnMNCj4+Pg0KPj4+IE9uIDEwLzI0LzEzIDI6MTcgUE0sIEFuZHJldyBB bGxlbiB3cm90ZToNCj4+Pj4gUGF1bA0KPj4+Pg0KPj4+PiBUaGF0IGlzIGZpbmUuIEFsdGhvdWdo IE1hcnkgaW4gaGVyIHJlcGx5IHRvIG1lIHNlZW1lZCB0byBpbmRpY2F0ZSBtYXliZSB0aGVyZSB3 YXMgYSBwb3NzaWJpbGl0eSB0byB1c2Ugc29tZSBvZiB0aGUgRElTUEFUQ0ggc3BhcmUgdGltZSBm b3IgYSBTSVBDT1JFIHNlc3Npb24gZm9yIHRoaXMuIElzIHRoYXQgYSBwb3NzaWJpbGl0eT8NCj4+ Pj4NCj4+Pj4gSSBhbHJlYWR5IHJlcGxpZWQgdG8geW91ciBwb3N0DQo+Pj4NCj4+PiBJIGRpc2N1 c3NlZCB0aGF0IHdpdGggQWRhbS4gV2UgZGVjaWRlZCB3ZSBjYW4ndCBzZXQgYSBwcmVjZWRlbnQg dG8NCj4+PiBzcGluIHVwIGEgc2Vzc2lvbiB0byBkaXNjdXNzIGEgZHJhZnQgdGhhdCBoYXNuJ3Qg aGFkIHN1YnN0YW50aWFsDQo+Pj4gKGFueSkgbGlzdCBkaXNjdXNzaW9uLg0KPj4+DQo+Pj4gQnV0 IGxpc3QgZGlzY3Vzc2lvbiBpcyBhbHdheXMgd2VsY29tZS4NCj4+Pg0KPj4+ICAgICAgU29ycnks DQo+Pj4gICAgICBQYXVsDQo+Pj4NCj4+Pj4gQW5kcmV3DQo+Pj4+DQo+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0 QGFsdW0ubWl0LmVkdV0NCj4+Pj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjQsIDIwMTMgMToz MSBQTQ0KPj4+PiBUbzogQW5kcmV3IEFsbGVuOyBHb256YWxvIENhbWFyaWxsbw0KPj4+PiBDYzog UmljaGFyZCBCYXJuZXMgKHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+KTsgQWRhbSBSb2Fj aCAoYWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4pOw0KPj4+PiBDaHJp c3RlciBIb2xtYmVyZyAoY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+KQ0KPj4+PiBTdWJqZWN0OiBSZTogTmV3IHNpcGNv cmUgZHJhZnQgc3VibWlzc2lvbg0KPj4+PiBkcmFmdC1hbGxlbi1zaXBjb3JlLXNpcC10cmVlLWNh cC1pbmRpY2F0b3JzDQo+Pj4+DQo+Pj4+IEFuZHJldywNCj4+Pj4NCj4+Pj4gSSBzcG9rZSB3aXRo IE1hcnkgYWJvdXQgaXQsIGFuZCB3ZSBjb25jbHVkZWQgdGhhdCBkaXNwYXRjaCBpc24ndCByaWdo dCBmb3IgdGhpcy4gKEluIGFkZGl0aW9uIHRvIGJlaW5nIGNsZWFybHkgc2lwY29yZSwgaXQgZGlk bid0IG1lZXQgdGhlIGRlYWRsaW5lIGZvciBkaXNwYXRjaC4pIEkgd2FzIHdyb25nIHRvIGVuY291 cmFnZSB5b3UgdGhhdCB3YXkuDQo+Pj4+DQo+Pj4+IFNvIG5vIG9mZmljaWFsIGxpdmUgZGlzY3Vz c2lvbiBpbiBWYW5jb3V2ZXIuIChCdXQgaW5mb3JtYWwNCj4+Pj4gZGlzY3Vzc2lvbg0KPj4+PiBm aW5lLikNCj4+Pj4NCj4+Pj4gSSdsbCByZXNlbmQgbXkgcHJpdmF0ZSBjb21tZW50cyB0byB0aGUg c2lwY29yZSBsaXN0IHRvIGtpY2tzdGFydCBzb21lIGRpc2N1c3Npb24gdGhlcmUuDQo+Pj4+DQo+ Pj4+ICAgICBUaGFua3MsDQo+Pj4+ICAgICBQYXVsDQo+Pj4+DQo+Pj4+IE9uIDEwLzI0LzEzIDE6 MDEgUE0sIEFuZHJldyBBbGxlbiB3cm90ZToNCj4+Pj4+IEkganVzdCBlbWFpbGVkIE1hcnkgYXNr aW5nIGZvciBhZ2VuZGEgdGltZS4gU2hvdWxkIEkgY2FuY2VsIHRoYXQgcmVxdWVzdD8NCj4+Pj4+ DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogR29uemFsbyBD YW1hcmlsbG8gW21haWx0bzpHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb21dDQo+Pj4+PiBT ZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNCwgMjAxMyAxOjAwIFBNDQo+Pj4+PiBUbzogUGF1bCBL eXppdmF0DQo+Pj4+PiBDYzogQW5kcmV3IEFsbGVuOyBSaWNoYXJkIEJhcm5lcyAocmxiQGlwdi5z eDxtYWlsdG86cmxiQGlwdi5zeD4pOyBBZGFtIFJvYWNoDQo+Pj4+PiAoYWRhbUBub3N0cnVtLmNv bTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4pOyBDaHJpc3RlciBIb2xtYmVyZw0KPj4+Pj4gKGNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPikNCj4+Pj4+IFN1YmplY3Q6IFJlOiBOZXcgc2lwY29yZSBkcmFmdCBzdWJtaXNz aW9uDQo+Pj4+PiBkcmFmdC1hbGxlbi1zaXBjb3JlLXNpcC10cmVlLWNhcC1pbmRpY2F0b3JzDQo+ Pj4+Pg0KPj4+Pj4gSGkgUGF1bCwNCj4+Pj4+DQo+Pj4+PiBnaXZlbiB0aGF0IHlvdSB0aGluayB0 aGlzIGJlbG9uZ3MgdG8gU0lQQ09SRSwgSSBkbyBub3Qgc2VlIHRoZSBuZWVkIHRvIHJ1biBpdCB0 aHJvdWdoIERJU1BBVENILiBQbGVhc2UsIHN0YXJ0IHRlY2huaWNhbCBkaXNjdXNzaW9ucyBvbiB0 aGUgZHJhZnQgb24gdGhlIFNJUENPUkUgbGlzdC4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MsDQo+Pj4+ Pg0KPj4+Pj4gR29uemFsbw0KPj4+Pj4NCj4+Pj4+IE9uIDIyLzEwLzIwMTMgOToxMSBQTSwgUGF1 bCBLeXppdmF0IHdyb3RlOg0KPj4+Pj4+IE9uIDEwLzIyLzEzIDE6MDAgUE0sIEFuZHJldyBBbGxl biB3cm90ZToNCj4+Pj4+Pj4gUGF1bA0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGFua3MgZm9yIHJldmll d2luZyB0aGUgZHJhZnQgYWxyZWFkeSBhbmQgZ2l2aW5nIG1lIGVhcmx5IGZlZWRiYWNrLg0KPj4+ Pj4+Pg0KPj4+Pj4+PiBNeSByZXNwb25zZXMgYmVsb3cgaW5saW5lIChwcmVwZW5kZWQgd2l0aCBb QUEpLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBDYW4gSSBhc2sgdGhlIEFEcyB0byBkZXRlcm1pbmUgQVNB UCBpZiB0aGlzIG5lZWRzIHRvIGdvIHRvDQo+Pj4+Pj4+IERJU1BBVENIIGZpcnN0IG9yIG5vdC4g QXMgb3V0bGluZWQgYmVsb3cgbXkgdmlldyBpcyB0aGF0IGl0IGlzDQo+Pj4+Pj4+IHVubmVjZXNz YXJ5IGZvciBldmVyeSBsaXR0bGUgdGhpbmcgdG8gZ28gdG8gRElTUEFUQ0ggYXMgdGhpcyBqdXN0 DQo+Pj4+Pj4+IGNyZWF0ZXMgYWRkaXRpb25hbCBkZWxheSBhbmQgb3ZlcmhlYWQuIElmIGl0IGlz IHRvIGJlIGRpc2N1c3NlZA0KPj4+Pj4+PiBpbiBESVNQQVRDSCB0aGVuIEkgZGVmaW5pdGVseSB3 b3VsZCB3YW50IGFnZW5kYSB0aW1lIGF0SUVURiM4OCBmb3IgdGhpcy4NCj4+Pj4+Pg0KPj4+Pj4+ IEhhdmluZyBub3cgc2VlbiBBbmRyZXcncyByZXNwb25zZXMgdG8gbXkgaW5pdGlhbCBxdWVzdGlv bnMsIEkNCj4+Pj4+PiB0aGluayB0aGlzDQo+Pj4+Pj4gKm5lZWRzKiB0byBiZSBjYXJlZnVsbHkg Y29uc2lkZXJlZCBieSBzaXBjb3JlLiBJTU8gdGhpcyBoYXMgdGhlDQo+Pj4+Pj4gcG90ZW50aWFs IHRvIGNyZWF0ZSBhIGRpYWxlY3Qgb2Ygc2lwIHRoYXQgaXMgaW5jb21wYXRpYmxlIHdpdGgNCj4+ Pj4+PiBub3JtYWwgdXNhZ2UuIChNYXliZSBJTVMgaGFzIGFscmVhZHkgZG9uZSB0aGF0LiBCdXQg dGhpcyB3aWxsIG1ha2UNCj4+Pj4+PiBpdA0KPj4+Pj4+IHdvcnNlLikNCj4+Pj4+Pg0KPj4+Pj4+ IEJ1dCBpZiB0aGVyZSBpcyBhIGRlc2lyZSB0byBkaXNjdXNzIGl0IHB1YmxpY2x5IGluIFZhbmNv dXZlciB0aGVuDQo+Pj4+Pj4gZGlzcGF0Y2ggaXMgdGhlIG9wcG9ydHVuaXR5IGFuZCBzbyBzb21l IGRpc2N1c3Npb24gb24gdGhlIGRpc3BhdGNoDQo+Pj4+Pj4gbGlzdCBpbiBhZHZhbmNlIG9mIHRo YXQgd291bGQgYmUgYXBwcm9wcmlhdGUuDQo+Pj4+Pj4NCj4+Pj4+PiBJJ2xsIGRlZmVyIHRvIHRo ZSBBRHMgb24gdGhpcy4NCj4+Pj4+Pg0KPj4+Pj4+IE1vcmUgaW5saW5lLg0KPj4+Pj4+DQo+Pj4+ Pj4+IEFuZHJldw0KPj4+Pj4+Pg0KPj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+Pj4+PiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHVd DQo+Pj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjIsIDIwMTMgMTA6MzMgQU0NCj4+Pj4+ Pj4gVG86IEFuZHJldyBBbGxlbjsgUmljaGFyZCBCYXJuZXMgKHJsYkBpcHYuc3g8bWFpbHRvOnJs YkBpcHYuc3g+KTsgR29uemFsbyBDYW1hcmlsbG8NCj4+Pj4+Pj4gKEdvbnphbG8uQ2FtYXJpbGxv QGVyaWNzc29uLmNvbTxtYWlsdG86R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tPik7IEFk YW0gUm9hY2ggKGFkYW1Abm9zdHJ1bS5jb208bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+KQ0KPj4+ Pj4+PiBTdWJqZWN0OiBSZTogTmV3IHNpcGNvcmUgZHJhZnQgc3VibWlzc2lvbg0KPj4+Pj4+PiBk cmFmdC1hbGxlbi1zaXBjb3JlLXNpcC10cmVlLWNhcC1pbmRpY2F0b3JzDQo+Pj4+Pj4+DQo+Pj4+ Pj4+IEFuZHJldywNCj4+Pj4+Pj4NCj4+Pj4+Pj4gT24gYSBsZWdhbGlzdGljIG5vdGUsIGl0cyBx dWVzdGlvbmFibGUgdG8gbWUgd2hldGhlciB0aGlzIGtpbmQgb2YNCj4+Pj4+Pj4gYWN0aW9uIGZh bGxzIHdpdGhpbiB0aGUgc2NvcGUgb2Ygc2lwY29yZS4gT1RPSCwgYW1vbmcgZXhpc3RpbmcNCj4+ Pj4+Pj4gd2dzLCBzaXBjb3JlIGlzIHByb2JhYmx5IHRoZSBiZXN0IHN1aXRlZCB0byBkaXNjdXNz IHRoZSBwcm9wb3NhbC4NCj4+Pj4+Pj4gV2UgY291bGQgdGFrZSBpdCB0byBESVNQQVRDSC4gSSB0 aGluayBESVNQQVRDSCBoYXMgZXh0cmEgdGltZSBpbg0KPj4+Pj4+PiBpdHMgYWdlbmRhIGZvciBW YW5jb3V2ZXIsIHNvIHRoYXQgbWlnaHQgYmUgb25lIG9wdGlvbiBmb3IgeW91Lg0KPj4+Pj4+PiBC dXQgdGhlbiBJIGRvbid0IGtub3cgd2hlcmUgZGlzcGF0Y2ggd291bGQgZGlzcGF0Y2ggaXQuIEl0 IG1heSBiZQ0KPj4+Pj4+PiB0aGF0IEFEIHNwb25zb3JlZCBpcyB0aGUgYmVzdCB3YXkgdG8gZ28u DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFtBQV0gSXQgc2VlbWVkIHRvIG1lIHRoYXQgc2lwY29yZSB3YXMg dGhlIHJpZ2h0IHBsYWNlLiBUaGlzIGRyYWZ0DQo+Pj4+Pj4+IHJlZ2lzdGVycyBmZWF0dXJlLWNh cGFiaWxpdHkgaW5kaWNhdG9ycyBpbiBhIHJlZ2lzdHJ5IHRoYXQgd2FzDQo+Pj4+Pj4+IGNyZWF0 ZWQgYnkgYSBzaXBjb3JlIFJGQyAoUkZDIDY4MDkpLiBZb3UgY291bGQgaW4gbXkgdmlldyBtYWtl IGFuDQo+Pj4+Pj4+IGFyZ3VtZW50IHRoYXQgdGhpcyBzaG91bGQgZXZlbiBoYXZlIGJlZW4gZG9u ZSBhcyBwYXJ0IG9mIFJGQyA2ODA5Lg0KPj4+Pj4+DQo+Pj4+Pj4gSWYgdGhpcyB3YXMganVzdCBh IG1hdHRlciBvZiByZWdpc3RlcmluZyBzb21lIG5ldyBmZWF0dXJlIGNhcHMNCj4+Pj4+PiB0aGF0 IHdlcmUgbm90IGNvbnRyb3ZlcnNpYWwsIHRoZW4gSSBkb24ndCB0aGluayBzaXBjb3JlIG5lZWRz IHRvIGJlIGludm9sdmVkLg0KPj4+Pj4+DQo+Pj4+Pj4gQnV0IGFzIEkgbWVudGlvbmVkIGFib3Zl LCBJIGRvIGNvbnNpZGVyIHRoZXNlIGNvbnRyb3ZlcnNpYWwuDQo+Pj4+Pj4NCj4+Pj4+Pj4gRGlz Y3Vzc2luZyBpdCBub3cgb24gdGhlIGRpc3BhdGNoIGxpc3Qgd291bGQgYmUgYSBnb29kIHN0YXJ0 DQo+Pj4+Pj4+IHRvd2FyZCBkaXNjdXNzaW5nIGl0IGF0IHRoZSBkaXNwYXRjaCBzZXNzaW9uLg0K Pj4+Pj4+Pg0KPj4+Pj4+PiBbQUFdIENhbiBJIGFzayB0aGUgQURzIHRvIGRldGVybWluZSBpZiB0 aGlzIG5lZWRzIHRvIGdvIHRvDQo+Pj4+Pj4+IERJU1BBVENIIGZpcnN0IG9yIG5vdC4gTXkgdmll dyBpcyB0aGF0IGl0IGlzIHVubmVjZXNzYXJ5IGZvcg0KPj4+Pj4+PiBldmVyeSBsaXR0bGUgdGhp bmcgdG8gZ28gdG8gRElTUEFUQ0ggYXMgdGhpcyBqdXN0IGNyZWF0ZXMgYWRkaXRpb25hbCBkZWxh eSBhbmQgb3ZlcmhlYWQuDQo+Pj4+Pj4+IFRoaXMganVzdCByZWdpc3RlcnMgc29tZSBpbmRpY2F0 b3JzIGluIGFuIGV4aXN0aW5nIElBTkEgcmVnaXN0cnkNCj4+Pj4+Pj4gYW5kIGlzIG5vdCAob3Ig c2hvdWxkIG5vdCBiZSBJTUhPKSBhIG1ham9yIHByb2plY3QuDQo+Pj4+Pj4NCj4+Pj4+PiBUbyBt ZSB0aGlzIGlzIGEgbWF0dGVyIG9mIHdoZXRoZXIgeW91IHdhbnQgdG8gYmUgb3Bwb3J0dW5pc3Rp Yy4NCj4+Pj4+PiBJZiB0aGlzIHdlbnQgdG8gZGlzcGF0Y2ggSSB3b3VsZCBub3cgcmVjb21tZW5k IHRoYXQgaXQgYmUNCj4+Pj4+PiBkaXNwYXRjaGVkIHRvIHNpcGNvcmUuIFNvIGl0cyBhIG1hdHRl ciBvZiB3aGV0aGVyIHlvdSB3YW50IHRvIHRhbGsNCj4+Pj4+PiBhYm91dCBpdCBpbiB0aGUgZGlz cGF0Y2ggbWVldGluZy4NCj4+Pj4+Pg0KPj4+Pj4+PiBSZWdhcmRpbmcgc3Vic3RhbmNlLCB0aGlz IGRyYWZ0IHRyb3VibGVzIG1lLiBJdCB0YWtlcw0KPj4+Pj4+PiBmZWF0dXJlLWNhcHMgaW4gZXhh Y3RseSB0aGUgZGlyZWN0aW9uIHRoYXQgSSBmb3VuZCBtb3N0DQo+Pj4+Pj4+IGNvbmNlcm5pbmcg YWJvdXQgdGhlIG1lY2hhbmlzbSBpbiB0aGUgZmlyc3QgcGxhY2UuDQo+Pj4+Pj4+DQo+Pj4+Pj4+ IFlvdXIgZHJhZnQgcGFydGl0aW9ucyB0aGUgZXhpc3RpbmcgbWVkaWEgZmVhdHVyZSB0YWdzIGlu dG8gdHdvDQo+Pj4+Pj4+IHNldHMNCj4+Pj4+Pj4gLSB0aG9zZSB0aGF0IHdvdWxkIGJlIHVzZWZ1 bCBhcyBmZWF0dXJlLWNhcGFiaWxpdHktaW5kaWNhdG9ycywNCj4+Pj4+Pj4gYW5kIHRob3NlIHRo YXQgYXJlbid0LiBCdXQgSSBzZWUgbm8gZXhwbGFuYXRpb24gb2YgdGhlIGNyaXRlcmlhDQo+Pj4+ Pj4+IHVzZWQgdG8gbWFrZSB0aGlzIGRpc3RpbmN0aW9uLCBub3IgY2FuIEkgdGhpbmsgb2Ygb25l Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBbQUFdIEkgYmFzZWQgdGhpcyBkZWNpc2lvbiBvbiB0aGUgZm9s bG93aW5nIGNyaXRlcmlhOiBJZiBhDQo+Pj4+Pj4+IGZlYXR1cmUgdGFnIHdhcyBwb3RlbnRpYWxs eSBhdCBhbGwgdXNlZnVsIGZvciBhbiBpbnRlcm1lZGlhcnkgdG8NCj4+Pj4+Pj4gaW5kaWNhdGUg aXQgdGhlbiBpbmNsdWRlIGl0IGluIHRoZSByZWdpc3RyeS4gVGhlIG9uZXMgbm90DQo+Pj4+Pj4+ IGluY2x1ZGVkIGFyZSBlaXRoZXIgZGlyZWN0bHkgYXNzb2NpYXRlZCB3aXRoIHRoZSB1c2VyDQo+ Pj4+Pj4+IChpbnRlcm1lZGlhcmllcyBhcmUgbm90ICBkaXJlY3RseSBhc3NvY2lhdGVkIHdpdGgg dGhlIHVzZXIpIG9yDQo+Pj4+Pj4+IHdvdWxkIG9ubHkgZXZlciBoYXZlIG9uZSB2YWx1ZSAoZS5n IGF1dG9tYXRhKS4gIEkgYW0gbm90IHN1cmUNCj4+Pj4+Pj4gdGhhdCBldmVyeSBmZWF0dXJlLWNh cGFiaWxpdHkgaW5kaWNhdG9yIHByb3Bvc2VkIHRvIGJlIHJlZ2lzdGVyZWQNCj4+Pj4+Pj4gaXMg YWN0dWFsbHkgdXNlZnVsIGJ1dCB0aGVuIEkgZG9uJ3QgdGhpbmsgZXZlcnkgbWVkaWEgZmVhdHVy ZSB0YWcNCj4+Pj4+Pj4gcmVnaXN0ZXJlZCBieSBSRkMgMzg0MCBpcyBlaXRoZXIgKEkgZG91YnQg dmVyeSBtdWNoIGlmIHRoZXJlIGFyZQ0KPj4+Pj4+PiBpbXBsZW1lbnRhdGlvbiB1c2luZyB0aGUg c2lwLmFwcGxpY2F0aW9uIG9yIHNpcC5jb250cm9sIGZlYXR1cmUNCj4+Pj4+Pj4gdGFncykuIEkg ZG9uJ3QgdGhpbmsgUkZDIDM4NDAgZ29lcyBpbnRvIGEgbG90IG9mIGRldGFpbHMNCj4+Pj4+Pj4g anVzdGlmeWluZyBvZiBldmVyIHJlZ2lzdGVyZWQgbWVkaWEgZmVhdHVyZSB0YWcgYW5kIHNwZWNp ZnlpbmcNCj4+Pj4+Pj4gdGhlIGRldGFpbHMgb2YgaG93IHRoZXkgd291bGQgYmUgdXNlZCBlaXRo ZXIuICBJIGFtIHdpbGxpbmcgdG8NCj4+Pj4+Pj4gcmVtb3ZlIGFueSBmZWF0dXJlLWNhcGFiaWxp dHkgaW5kaWNhdG9ycyB0aGF0IGFyZSBjb250cm92ZXJzaWFsIGV4Y2VwdCB0aGF0IEkgdGhpbmsg d2UgZGVmaW5pdGVseSBuZWVkIHNpcC5leHRlbnNpb25zLCBzaXAubWV0aG9kcyBhbmQgc2lwLmV2 ZW50cy4NCj4+Pj4+Pj4gVGhlcmUgaXMgYSBzaWduaWZpY2FudCBvdmVyaGVhZCB0byB3cml0aW5n IGFuDQo+Pj4+Pj4gZCBwcm9ncmVzc2luZyBpbnRlcm5ldCBkcmFmdHMgc28gbXkgdmlldyBpcyBs ZXRzIHJlZ2lzdGVyIGFsbCB0aGF0DQo+Pj4+Pj4gbWlnaHQgYmUgcmVtb3RlbHkgdXNlZnVsIGlu IHRoZSBzYW1lIGRvY3VtZW50Lg0KPj4+Pj4+DQo+Pj4+Pj4gVGhlIGp1ZGdlbWVudCBvZiAidXNl ZnVsIiBpcyByZWFzb25hYmxlLiBCdXQgSSBzdGlsbCBjYW4ndCBkaXNjZXJuDQo+Pj4+Pj4gd2hh dCB0aGUgdXNlIGlzIGZyb20gdGhlIGlhbmEgcmVnaXN0cmF0aW9uIGRlc2NyaXB0aW9ucy4NCj4+ Pj4+Pg0KPj4+Pj4+PiBGb3IgdGhlIG9uZXMgdGhhdCB5b3UgaGF2ZSByZXF1ZXN0ZWQgZmVhdHVy ZSBjYXBhYmlsaXR5DQo+Pj4+Pj4+IGluZGljYXRvcnMsIEkgY2Fubm90IGZpZ3VyZSBvdXQgd2hh dCB1c2luZyB0aGVtIHdvdWxkIG1lYW4uIEZvcg0KPj4+Pj4+PiBleGFtcGxlLCB3aGVuIEkgc2Vl IGlzRm9jdXMgb24gYSBDb250YWN0IGhlYWRlciBJIGtub3cgSSBhbSBpbiBhDQo+Pj4+Pj4+IGNv bmZlcmVuY2UsIGFuZCB0aGF0IEkgY2FuIHN1YnNjcmliZSB0byB0aGUgY29uZmVyZW5jZSBldmVu dA0KPj4+Pj4+PiBwYWNrYWdlIGF0IHRoZSBjb250YWN0IFVSSS4gSWYgSSBzZWUgaXNGb2N1cyBp biBhIEZlYXR1cmUtQ2FwcyBoZWFkZXIsIHdoYXQgZG9lcyBpdCBtZWFuPw0KPj4+Pj4+PiBXaGF0 IGNhbiBJIGRvIG9uY2UgSSBrbm93IHRoaXM/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFNlY3Rpb24gNS4x NCBvZiB0aGlzIGRyYWZ0IHNheXM6DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICBUaGlz IEZlYXR1cmUtY2FwYWJpbGl0eSBpbmRpY2F0b3IgaW5kaWNhdGVzIHRoYXQgdGhlIGludGVybWVk aWFyeQ0KPj4+Pj4+PiAgICAgICAgICAgICAgaXMgYSBjb25mZXJlbmNlIHNlcnZlciwgYWxzbyBr bm93biBhcyBhIGZvY3VzLCBhbmQgaXMgY2FwYWJsZSBvZg0KPj4+Pj4+PiAgICAgICAgICAgICAg bWl4aW5nIHRvZ2V0aGVyIHRoZSBtZWRpYSBmb3IgYWxsIGNhbGxzIHRvIHRoZSBzYW1lIFVSSS4N Cj4+Pj4+Pj4gLi4uDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICBFeGFtcGxlcyBvZiB0eXBpY2Fs IHVzZTogQSBjb25mZXJlbmNlIGJyaWRnZQ0KPj4+Pj4+PiBpbmRpY2F0aW5nIHRoYXQgaXQNCj4+ Pj4+Pj4gICAgICAgICAgICAgICAgIGlzIGEgY29uZmVyZW5jZSBicmlkZ2UgYW5kIGlzIGNhcGFi bGUgb2YgYWN0aW5nIGFzDQo+Pj4+Pj4+IGEgY29uZmVyZW5jZQ0KPj4+Pj4+PiAgICAgICAgICAg ICAgICAgZm9jdXMgZm9yIHRoaXMgc2Vzc2lvbi4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gW0FBXSB0aGUg cHJlc2VuY2Ugb2YgaXNmb2N1cyBpbiBhIEZlYXR1cmUtQ2FwcyBoZWFkZXIgZmllbGQgbWVhbnMN Cj4+Pj4+Pj4gdGhhdCBhIFVBIGNhbiBpbml0aWF0ZSBhIGNvbmZlcmVuY2UgYnkgc2VuZGluZyBh IFJFRkVSIHJlcXVlc3QgdG8NCj4+Pj4+Pj4gdGhlIGludGVybWVkaWFyeSB0byBpbnZpdGUgYW5v dGhlciB1c2VyIGFuZCBjcmVhdGUgYSBtdWx0aSB1c2VyDQo+Pj4+Pj4+IGNvbmZlcmVuY2UgZnJv bSB0aGUgMS0xIHNlc3Npb24uDQo+Pj4+Pj4+DQo+Pj4+Pj4+IE5vdGUgdGhhdCBGZWF0dXJlLUNh cHMgZG9lc24ndCBpbmRpY2F0ZSB3aGljaCBlbnRpdHkgaGFzIHRoaXMNCj4+Pj4+Pj4gY2FwYWJp bGl0eSwgb25seSB0aGF0IHNvbWV0aGluZyBkb2VzLiBBbmQgc2luY2UgdGhpcyB3b3VsZA0KPj4+ Pj4+PiBwcmVzdW1hYmx5IG9ubHkgYmUgdXNlZCBpZiBpdCB3YXNuJ3QgdGhlIFVBQyBvZiB0aGUg cmVxdWVzdCwNCj4+Pj4+Pj4gc2VuZGluZyBhIHN1YnNjcmliZSB0byB0aGUgY29udGFjdCBhZGRy ZXNzIG9mIHRoZSBVQUMgd291bGRuJ3QgbWFrZSBzZW5zZS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gW0FB XSBZZXMgdGhlIEdSVVUgb2YgdGhlIGludGVybWVkaWFyeSB3b3VsZCBiZSBuZWVkZWQgYnV0IEkN Cj4+Pj4+Pj4gY29uc2lkZXIgdGhpcyBhcHBsaWNhdGlvbiBzcGVjaWZpYyBhbmQgc28gdGhpcyB3 b3VsZCBiZSBpbmNsdWRlZA0KPj4+Pj4+PiBpbiBhIGZlYXR1cmUgdGFnIHJlZ2lzdGVyZWQgaW4g dGhlIGdsb2JhbCB0cmVlIGFzIHN0YXRlZCBpbiB0aGUNCj4+Pj4+Pj4gZHJhZnQgIlJGQyA2ODA5 IFsxXSBwcm92aWRlcyB0aGF0IGFkZHJlc3NlcyBvZiBpbnRlcm1lZGlhcmllcyBjYW4NCj4+Pj4+ Pj4gYmUgY29tbXVuaWNhdGVkIGFzIGEgdmFsdWUgb2YgYW4gYXNzb2NpYXRlZCBmZWF0dXJlLWNh cGFiaWxpdHkNCj4+Pj4+Pj4gaW5kaWNhdG9yIHNvIGl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRv IGRlZmluZSBmZWF0dXJlIGNhcGFiaWxpdHkNCj4+Pj4+Pj4gaW5kaWNhdG9ycyBhcyBwYXJ0IG9m IHRoZSBnbG9iYWwgdHJlZSB0byBjb21tdW5pY2F0ZSB0aGUgR1JVVSBvZg0KPj4+Pj4+PiB0aGUg aW50ZXJtZWRpYXJ5IGFuZCBoZW5jZSB0aGlzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMN Cj4+Pj4+Pj4gZG9jdW1lbnQuIiAgLSBSRkMgNjgwOSBzdGF0ZXMgIiBJZiBhZGRpdGlvbmFsIGRh dGEgYWJvdXQgYQ0KPj4+Pj4+PiBzdXBwb3J0ZWQgZmVhdHVyZSBuZWVkcyB0byBiZSBjb252ZXll ZCwgc3VjaCBhcyB0aGUgYWRkcmVzcyBvZg0KPj4+Pj4+PiB0aGUgU0lQIGVudGl0eSB0aGF0IGlu ZGljYXRlZCBzdXBwb3J0IG9mIHRoZSBmZWF0dXJlLCB0aGVuIHRoZQ0KPj4+Pj4+PiBmZWF0dXJl IGRlZmluaXRpb24gbmVlZHMgdG8gZGVmaW5lIGEgd2F5IHRvIGNvbnZleSB0aGF0DQo+Pj4+Pj4+ IGluZm9ybWF0aW9uIGFzIGEgdmFsdWUgb2YgdGhlIGFzc29jaWF0ZWQgZmVhdHVyZS1jYXBhYmls aXR5DQo+Pj4+Pj4+IGluZGljYXRvci4iIEhvd2V2ZXIgSSB0aGluayB0aGUgU0lQIHNwZWNpZmlj IGNhcGFiaWxpdHkNCj4+Pj4+Pj4gaW5kaWNhdG9ycyBzdWNoIGFzIG1ldGhvZHMsIGV4dGVuc2lv bnMgYW5kIGV2ZW50cyBzaG91bGQNCj4+Pj4+Pj4gYXBwcm9wcmlhdGVseSBiZSByZWdpc3RlcmVk IGluIHRoZSBTSVAgdHJlZSBub3QgYXMgcHJvcHJpZXRhcnkNCj4+Pj4+Pj4gaW5kaWNhdG9yDQo+ Pj4+Pj4gcyBpbiB0aGUgZ2xvYmFsIHRyZWUuDQo+Pj4+Pj4NCj4+Pj4+PiBTbyB5b3UgaGF2ZSBk ZWZpbmVkIGEgc2lwIHRyZWUgZmVhdHVyZSB0YWcgdGhhdCBpcyBvbmx5IHVzZWZ1bCBpbg0KPj4+ Pj4+IGNvbmp1bmN0aW9uIHdpdGggYW5vdGhlciBmZWF0dXJlIHRhZyBmcm9tIHRoZSBnbG9iYWwg dHJlZS4NCj4+Pj4+PiBBbmQgdGhlIGRlc2NyaXB0aW9uIG9mIHRoaXMgZmVhdHVyZSB0YWcgZG9l c24ndCBldmVuIG1lbnRpb24gdGhhdC4NCj4+Pj4+Pg0KPj4+Pj4+IEFuZCB0aGlzIGFsbCBpbXBs aWVzIGEgY29tcGxldGVseSBub24tc3RhbmRhcmQgY2FsbCBtb2RlbCAtIGRvaW5nDQo+Pj4+Pj4g Y29uZmVyZW5jaW5nIGluIGEgd2F5IGluY29uc2lzdGVudCB3aXRoIFJGQyA0NTc5Lg0KPj4+Pj4+ DQo+Pj4+Pj4gSVNUTSB0aGF0IGlmIDQ1NzkgZG9lc24ndCB3b3JrIGZvciB5b3UgdGhlbiB5b3Ug c2hvdWxkIGJlIGJhY2sNCj4+Pj4+PiBwcm9wb3NpbmcgZXh0ZW5zaW9ucy9yZXZpc2lvbnMgdG8g aXQuDQo+Pj4+Pj4NCj4+Pj4+Pj4gSWYgdGhlcmUgaXMgYSBjb25mZXJlbmNlIGJyaWRnZSBpbiB0 aGUgc2lnbmFsaW5nIHBhdGgsIHRoZW4gSQ0KPj4+Pj4+PiB3b3VsZCBleHBlY3QgaXQgdG8gYmUg dGhlIFVBQy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gW0FBXSBBbHRob3VnaCBhICJzdGFuZGFyZCIgd2F5 IHRvIGludm9rZSBhIGNvbmZlcmVuY2UgaXMgdG8gc2VuZA0KPj4+Pj4+PiBhIFJFRkVSIHRvIHRo ZSBvdGhlciBVQXMgdG8gaW52aXRlIHRoZW0gdG8gdGhlIGNvbmZlcmVuY2UgZm9jdXMsDQo+Pj4+ Pj4+IGluIG1hbnkgZGVwbG95bWVudHMgYSBzY2VuYXJpbyBleGlzdHMgd2hlcmUgYSBjYWxsIGlu dm9sdmVzIGFuDQo+Pj4+Pj4+IElQLVBCWCBvciBUZWxlcGhvbnkgQXBwbGljYXRpb24gU2VydmVy IChUQVMpIHRoYXQgY2FuIGFjdCBhcyBhDQo+Pj4+Pj4+IGZvY3VzIGZvciB0aGUgY29uZmVyZW5j ZS4gQSBwYXJ0aWNpcGFudCBvZiBhIGNhbGwgY2FuIHRoZW4gY3JlYXRlDQo+Pj4+Pj4+IGEgY29u ZmVyZW5jZSBieSBzZW5kaW5nIGEgUkVGRVIgcmVxdWVzdCBpbiBkaWFsb2cgdG8gdGhlIElQLVBC WA0KPj4+Pj4+PiBvciBUQVMgdG8gdXNlIDNQQ0MgdG8gSW52aXRlIG90aGVyIHVzZXJzIHRvIGEg Y29uZmVyZW5jZS4gUmVhc29ucyBmb3IgdGhpcyBhcmUgMS4NCj4+Pj4+Pj4gTm90IGFsbCBVQXMg c3VwcG9ydCBSRUZFUiwNCj4+Pj4+Pg0KPj4+Pj4+IFNvIHlvdSBhcmUgc2F5aW5nIHRoZSBpbnRl cm1lZGlhcnkgaXNuJ3QgYSBmb2N1cyAoaXRzIGEgQjJCVUEpLA0KPj4+Pj4+IGJ1dCBpdCAqY291 bGQgYmVjb21lKiBhIGZvY3VzLg0KPj4+Pj4+DQo+Pj4+Pj4gVGhlIGNvbmNlcHQgdGhhdCBhIGRp YWxvZyBtYXkgY29udGFpbiBpbnRlcm1lZGlhcmllcyB0aGF0IGNhbiBiZQ0KPj4+Pj4+IGFkZHJl c3NlZCB0byBkbyBzdHVmZiBpcyBub3QgcGFydCBvZiBhbnkgc2lwIHN0YW5kYXJkIHRoYXQgSSBh bQ0KPj4+Pj4+IGF3YXJlIG9mLiBJIGRvbid0IGNhcmUgdG9vIG11Y2ggYXMgbG9uZyBhcyB0aGUg InN0dWZmIiBpcw0KPj4+Pj4+IGFwcGxpY2F0aW9uIHN0dWZmIHRoYXQgaXMgb3V0c2lkZSB0aGUg c2NvcGUgb2Ygc2lwLiBCdXQgd2hlbiBpdCBpcw0KPj4+Pj4+IGFsdGVybmF0aXZlIHdheXMgdG8g ZG8gc3R1ZmYgdGhhdCBzaXAgc3VwcG9ydHMsIHRoZW4gSSBnZXQgdXBzZXQuDQo+Pj4+Pj4NCj4+ Pj4+Pj4gMi4gTWFueSBTQkNzIHJlamVjdCBSRUZFUiByZXF1ZXN0cyBnb2luZyBvdXRzaWRlIGRv bWFpbnMgYmVjYXVzZQ0KPj4+Pj4+PiBvZiB0aGUgcG90ZW50aWFsIGZvciBjaGFyZ2luZyBmcmF1 ZCAocmVmZXJyaW5nIHRvIGEgcHJlbWl1bSByYXRlDQo+Pj4+Pj4+IG51bWJlcg0KPj4+Pj4+PiBl dGMpIDMuIEEgVXNlciByZWNlaXZpbmcgYSBSRUZFUiBhbmQgdGhlbiB1c2luZyBhbiBJTlZJVEUg dG8gam9pbg0KPj4+Pj4+PiB0aGUgY29uZmVyZW5jZSBtYXkgYmUgY2hhcmdlZCBmb3IgaW5pdGlh dGluZyAgdGhlIGNhbGwgd2hlbiB0aGUNCj4+Pj4+Pj4gc2NlbmFyaW8gaXMgdGhhdCB0aGUgaW5p dGlhdG9yIG9mIHRoZSBjb25mZXJlbmNlIHNob3VsZCBiZSBjaGFyZ2VkLg0KPj4+Pj4+PiA0LiBO byBuZWVkIHRvIG9idGFpbiBhbmQgZGlzdHJpYnV0ZSBjb25mZXJlbmNlIFVSSXMuDQo+Pj4+Pj4+ IFByb2JsZW0gaXMgaG93IHRvIGFjaGlldmUgdGhlIHNhbWUgYmVoYXZpb3Igd2l0aG91dCBkaWFs b2cgcmV1c2UNCj4+Pj4+Pj4gd2hpY2ggaGFzIGJlZW4gZGVwcmVjYXRlZCBieSBSRkMgNjY2NT8N Cj4+Pj4+Pg0KPj4+Pj4+IFRoZW4gbWF5YmUgdGhlIHByb2JsZW0gbmVlZHMgdG8gYmUgYnJvdWdo dCB1cCwgYW5kIGEgc3RhbmRhcmQNCj4+Pj4+PiBzb2x1dGlvbiBwcm9wb3NlZCwgcmF0aGVyIHRo YW4gc2ltcGx5IGVuYWJsaW5nIGEgcHJvcHJpZXRhcnkgbWVjaGFuaXNtLg0KPj4+Pj4+DQo+Pj4+ Pj4+IEFzIGFub3RoZXIgZXhhbXBsZSwgY29uc2lkZXIgc2VjdGlvbiA1LjE6DQo+Pj4+Pj4+DQo+ Pj4+Pj4+ICAgICAgICAgICAgICBEZXNjcml0aW9uOg0KPj4+Pj4+PiAgICAgICAgICAgICAgVGhp cyBGZWF0dXJlLWNhcGFiaWxpdHkgaW5kaWNhdG9yIGluZGljYXRlcyB0aGF0IHRoZSBpbnRlcm1l ZGlhcnkNCj4+Pj4+Pj4gICAgICAgICAgICAgIHN1cHBvcnRzIGF1ZGlvIGFzIGEgc3RyZWFtaW5n IG1lZGlhIHR5cGUuDQo+Pj4+Pj4+IC4uLg0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgRXhhbXBs ZXMgb2YgdHlwaWNhbCB1c2U6IEFuIElQIFBCWCBpbmRpY2F0aW5nIHRoYXQgaXQgaXMNCj4+Pj4+ Pj4gICAgICAgICAgICAgICAgIGNhcGFibGUgb2YgYWNjZXB0aW5nIGFuZCBpbml0aWF0aW5nIHNl c3Npb25zIHdpdGggYXVkaW8gYXMgYQ0KPj4+Pj4+PiAgICAgICAgICAgICAgICAgc3RyZWFtaW5n IG1lZGlhIHR5cGUuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoaXMgZGVmaW5pdGlvbiAqaW1wbGllcyog YW4gYXNzdW1wdGlvbiBhYm91dCB0aGUgd29ya2luZw0KPj4+Pj4+PiBlbnZpcm9ubWVudA0KPj4+ Pj4+PiAtIG9uZSB0aGF0IEFGQUlLIGlzIG5ldy4gSXQgaW1wbGllcyB0aGF0IHlvdSBuZWVkIHRv IGtub3cgdGhhdA0KPj4+Pj4+PiBpbnRlcm1lZGlhcmllcyBzdXBwb3J0IGEgbWVkaWEgdHlwZSBi ZWZvcmUgeW91IGNhbiB1c2UgaXQuIFdvdWxkDQo+Pj4+Pj4+IGl0IGJlIGJhZCBpZiB0aGVyZSB3 ZXJlIG5vIGludGVybWVkaWFyaWVzLCBhbmQgc28gbm9uZSBpbmRpY2F0ZWQgdGhpcz8NCj4+Pj4+ Pj4gV2hhdCBpZiBzb21lIGludGVybWVkaWFyeSAqZGlkKiBpbmRpY2F0ZSBzdXBwb3J0LCBidXQg c29tZSBvdGhlcg0KPj4+Pj4+PiBkb2Vzbid0LCBidXQgZG9lc24ndCBpbmRpY2F0ZSB0aGF0IGl0 IGRvZXNuJ3Q/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEJvdHRvbSBsaW5lOiBob3cgd291bGQgdGhlIHBy ZXNlbmNlIG9yIGFic2VuY2Ugb2YgdGhpcyBmZWF0dXJlDQo+Pj4+Pj4+IHRhZyBhZmZlY3Qgc3Vi c2VxdWVudCB1c2FnZT8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gW0FBXSBUaGUgYWJzZW5jZSBvZiB0aGUg c3RyZWFtaW5nIHR5cGVzIGRvZXMgbm90IGluZGljYXRlIHRoYXQNCj4+Pj4+Pj4gdGhlIGludGVy bWVkaWFyeSBkb2VzIG5vdCBzdXBwb3J0IHRoZSBtZWRpYSB0eXBlIGFuZCBTRFAgb2ZmZXINCj4+ Pj4+Pj4gYW5zd2VyIHdpbGwgdWx0aW1hdGVseSBkZXRlcm1pbmUgd2hhdCBjYW4gb3IgY2Fubm90 IGJlIHVzZWQgaWYNCj4+Pj4+Pj4gYW5vdGhlciBzZXNzaW9uIGlzIGluaXRpYXRlZCBpbnZvbHZp bmcgdGhlIGludGVybWVkaWFyeS4gSG93ZXZlcg0KPj4+Pj4+PiB0aGUgcHJlc2VuY2Ugb2YgdGhl IG1lZGlhIHR5cGUgaW4gYSBGZWF0dXJlLWNhcHMgaGVhZGVyIGZpZWxkDQo+Pj4+Pj4+IGRvZXMg ZXhwbGljdGx5IGNvbmZpcm0gdGhhdCB0aGUgaW50ZXJtZWRpYXJ5IGRvZXMgc3VwcG9ydCB0aGUN Cj4+Pj4+Pj4gbWVkaWEgdHlwZSBhbmQgaW4gdGhlIHNjZW5hcmlvIHdoZXJlIGEgVUEgaGFzIGEg Y2hvaWNlIG9mDQo+Pj4+Pj4+IG11bHRpcGxlIGludGVybWVkaWFyaWVzIGl0IGNvdWxkIHVzZSBm b3IgYSBjb25mZXJlbmNlIGl0IG1pZ2h0DQo+Pj4+Pj4+IGNob29zZSB0byB1c2UgdGhlIG9uZSB0 aGF0IGV4cGxpY2l0bHkgaW5kaWNhdGVzIGl0IHN1cHBvcnRzIHRoZSBtZWRpYSB0eXBlcyB0aGUg VUEgd2FudHMgdG8gdXNlLg0KPj4+Pj4+DQo+Pj4+Pj4gU28gdGhlIFVBIHdpbGwgYmUgYWJsZSB0 byBkaXNjb3ZlciB0aGF0ICpzb21lKiBpbnRlcm1lZGlhcnkNCj4+Pj4+PiBzdXBwb3J0cyBtZWRp YSBpdCBpcyBpbnRlcmVzdGVkIGluLiBBbmQgaXQgY2FuIHRlbGwgdGhhdCAqc29tZSoNCj4+Pj4+ PiBpbnRlcm1lZGlhcnkgc2F5cyBpdCBpcyBhIGZvY3VzLiBJdCBkb2Vzbid0IGtub3cgaWYgdGhl eSBhcmUgdGhlIHNhbWUgaW50ZXJtZWRpYXJ5Lg0KPj4+Pj4+DQo+Pj4+Pj4gQW5kIHRoZW4gdmlh IHNvbWUgb3RoZXIgZmVhdHVyZSB0YWcgaXQgb2J0YWlucyB0aGUgVVJJIG9mICpzb21lKg0KPj4+ Pj4+IGludGVybWVkaWFyeSBvbiB0aGUgc2lnbmFsaW5nIHBhdGguIE9yIG1heWJlIGl0IGdldHMg bW9yZSB0aGFuIG9uZQ0KPj4+Pj4+IG9mIHRoZXNlLg0KPj4+Pj4+DQo+Pj4+Pj4gSXQgdGhlbiBt YWtlcyBhIGxlYXAgb2YgZmFpdGggYW5kIGNvbmZsYXRlcyBhbGwgdGhvc2UgdGhpbmdzLCB0bw0K Pj4+Pj4+IGRldGVybWluZSB0aGF0IHRoZSBVUkkgaWRlbnRpZmllcyBhIGZvY3VzIHRoYXQgc3Vw cG9ydHMgdGhpcyBtZWRpYSB0eXBlLg0KPj4+Pj4+DQo+Pj4+Pj4gRXZlbiB0aGVuLCBleGFjdGx5 IHdoYXQgZG9lcyB0aGF0IG1lYW4/IEl0IG1heSBvciBtYXkgbm90IG1lYW4NCj4+Pj4+PiB0aGF0 IGl0IHN1cHBvcnRzIG1peGluZyB0aGF0IG1lZGlhIHR5cGUgaW4gYSBjb25mZXJlbmNlLg0KPj4+ Pj4+DQo+Pj4+Pj4+IEFzIEkgc3RhdGVkIGFscmVhZHkgSSBkb24ndCBjYXJlIHRoYXQgbXVjaCBh Ym91dCB0aGVzZSBzdHJlYW1pbmcNCj4+Pj4+Pj4gbWVkaWEgdHlwZXMuDQo+Pj4+Pj4NCj4+Pj4+ Pj4gSSBjb3VsZCBnbyBvbiwgYnV0IHRoaXMgaXMgZW5vdWdoIGZvciBub3cuDQo+Pj4+Pj4+DQo+ Pj4+Pj4+IFtBQV0gTXkgbW90aXZhdGlvbiBmb3IgdGhpcyBpcyB0aGF0IGN1cnJlbnRseSAzR1BQ IGFyZSB1cGRhdGluZw0KPj4+Pj4+PiB0aGVpciBzcGVjaWZpY2F0aW9ucyB0byB1c2UgUkZDIDY2 NjUgaW5zdGVhZCBvZiBSRkMgMzI2NS4NCj4+Pj4+Pg0KPj4+Pj4+PiAzR1BQIGhhcyBhIGxvdCBv ZiBkaWFsb2cgcmV1c2Ugd2l0aCBTVUJTQ1JJQkUgYW5kIFJFRkVSIHdpdGgNCj4+Pj4+Pj4gaW50 ZXJtZWRpYXJpZXMgYWNjZXB0aW5nIHRoZSBSRUZFUiBvciBTVUJTQ1JJQkUgcmVxdWVzdCByYXRo ZXINCj4+Pj4+Pj4gdGhhbiBmb3J3YXJkaW5nIGl0IGFsbCB0aGUgd2F5IHRvIHRoZSByZW1vdGUg VUEuDQo+Pj4+Pj4NCj4+Pj4+PiBBbmQgNjY2NSBkZXByZWNhdGVzIGRpYWwgcmV1c2UgaW4gbW9z dCBvZiB0aG9zZSBjYXNlcy4NCj4+Pj4+PiBXaXRob3V0IGRpYWxvZyByZXVzZSwgdGhlIGludGVy bWVkaWFyaWVzIGRvbid0IGdldCBhbiBvcHBvcnR1bml0eQ0KPj4+Pj4+IHRvIGludGVyY2VwdCB0 aG9zZS4NCj4+Pj4+Pg0KPj4+Pj4+PiBJbiBvcmRlciB0byBrbm93IHRoYXQgYW4gaW50ZXJtZWRp YXJ5IHN1cHBvcnRzIHRoZSB0YXJnZXQgZGlhbG9nDQo+Pj4+Pj4+IG1lY2hhbmlzbSAgbmVlZGVk IGZvciBhIFJFRkVSIHJlcXVlc3Qgc2VudCBvdXRzaWRlIHRoZSBkaWFsb2cgdG8NCj4+Pj4+Pj4g d29yayB3ZSBuZWVkIHNpcC5leHRlbnNpb25zIGFzIGEgZmVhdHVyZS1jYXBhYmlsaXR5IGluZGlj YXRvci4gSW4NCj4+Pj4+Pj4gb3JkZXIgdG8ga25vdyB0aGF0IHRoZSBuZWVkZWQgZXZlbnQgcGFj a2FnZSBpcyBzdXBwb3J0ZWQgYnkgdGhlDQo+Pj4+Pj4+IGludGVybWVkaWFyeSBzbyB3ZSBjYW4g U1VCU0NST0JFIG91dHNpZGUgdGhlIGRpYWxvZyB0byBhbg0KPj4+Pj4+PiBpbnRlcm1lZGlhcnkg d2UgbmVlZCBzaXAuZXZlbnRzIGFzIGEgZmVhdHVyZS1jYXBhYmlsaXR5IGluZGljYXRvci4NCj4+ Pj4+Pg0KPj4+Pj4+IFRoZW4gSSB0aGluayB5b3Ugc2hvdWxkIGJlIGJhY2sgaGVyZSB3aXRoIGEg cHJvYmxlbSBzdGF0ZW1lbnQgYW5kDQo+Pj4+Pj4gYSByZXF1ZXN0IGZvciBob3cgdG8gZ2V0IHNp cCB0byBzb2x2ZSBpdC4NCj4+Pj4+Pg0KPj4+Pj4+IEFuZCB5b3Ugc2hvdWxkIHRvdWNoIGJhc2Ug d2l0aCBDaHJpc3RlciBvbiB0aGlzLiBIZSBtYXkgaGF2ZSBhDQo+Pj4+Pj4gZGlmZmVyZW50IG9w aW5pb24gb24gdGhlIHJlbGV2YW5jZSBvZiBmZWF0dXJlLWNhcHMgYXMgYSBzb2x1dGlvbi4NCj4+ Pj4+Pg0KPj4+Pj4+ICAgICAgICAgIFRoYW5rcywNCj4+Pj4+PiAgICAgICAgICBQYXVsDQo+Pj4+ Pj4NCj4+Pj4+Pj4gT24gMTAvMjIvMTMgMzo0NCBBTSwgQW5kcmV3IEFsbGVuIHdyb3RlOg0KPj4+ Pj4+Pj4gQWRhbSwgUGF1bCwgUmljaGFyZCwgR29uemFsbw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEkg aGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdG8gc2lwY29yZSAgdG8gcmVnaXN0ZXIgYSBudW1i ZXIgb2YNCj4+Pj4+Pj4+IGZlYXR1cmUgY2FwYWJpbGl0eSBpbmRpY2F0b3JzIGluIHRoZSBTSVAg dHJlZSAoYmFzZWQgdXBvbiBzb21lDQo+Pj4+Pj4+PiBvZiB0aGUgZXhpc3RpbmcgU0lQIG1lZGlh IGZlYXR1cmUgdGFncykuIFRoZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6DQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1hbGxlbi1zaXBjb3JlLXNpcC10cmVl LWNhcC1pbmRpY2F0b3JzLTAwLg0KPj4+Pj4+Pj4gdHh0DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gU2lu Y2UgdGhlcmUgd2lsbCBub3QgYmUgYSBzaXBjb3JlIHNlc3Npb24gYXQgSUVURiM4OCAgY2FuIHdl DQo+Pj4+Pj4+PiBoYXZlIGFuIG9mZmxpbmUgZGlzY3Vzc2lvbiBvbiBob3cgdG8gcHJvZ3Jlc3Mg dGhpcyBkcmFmdCAod2hpY2gNCj4+Pj4+Pj4+IGhvcGVmdWxseSBpcyBmYWlybHkgc3RyYWlnaHRm b3J3YXJkIGFzIGl0IGp1c3QgcmVnaXN0ZXJzIGZlYXR1cmUNCj4+Pj4+Pj4+IGNhcGFiaWxpdGll cyBpbmRpY2F0b3JzIHdpdGggSUFOQSkuIEkgd291bGRuJ3Qgd2FudCB0byBoYXZlIHRvDQo+Pj4+ Pj4+PiB3YWl0IHVudGlsIE1hcmNoIG5leHQgeWVhciBmb3IgYSBkZWNpc2lvbiBvbiBwcm9ncmVz c2luZyB0aGlzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEFuZHJldw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4+Pj4+Pj4+IC0tLQ0KPj4+Pj4+Pj4gLQ0KPj4+Pj4+Pj4gLSBUaGlzIHRyYW5z bWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4NCj4+Pj4+Pj4+ IGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5n DQo+Pj4+Pj4+PiBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Ig b3RoZXIgYXBwbGljYWJsZQ0KPj4+Pj4+Pj4gcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9u LXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZg0KPj4+Pj4+Pj4gdGhpcyBpbmZvcm1hdGlv biBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzDQo+Pj4+Pj4+ PiBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBl cnJvciwNCj4+Pj4+Pj4+IHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcw0KPj4+Pj4+Pj4gaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNl LCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sDQo+Pj4+Pj4+PiBvciByZXByb2R1Y3Rpb24g b2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRo b3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ Pj4+Pj4+IC0tLQ0KPj4+Pj4+PiAtIFRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0 dGFjaG1lbnRzKSBtYXkgY29udGFpbg0KPj4+Pj4+PiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24s IHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbA0KPj4+Pj4+PiBwcm90ZWN0 ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZQ0KPj4+Pj4+PiBw cml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNl IG9mDQo+Pj4+Pj4+IHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGlu dGVuZGVkIHJlY2lwaWVudCBpcw0KPj4+Pj4+PiBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwNCj4+Pj4+Pj4gcGxlYXNlIGltbWVkaWF0 ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzDQo+Pj4+Pj4+IGluZm9ybWF0 aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLA0K Pj4+Pj4+PiBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRl ZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo+Pj4+ Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+DQo+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+PiAtLSBU aGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4N Cj4+Pj4+IGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5j bHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhl ciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3Jt YXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8g dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4g VXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlz IHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQg YW5kIG1heSBiZSB1bmxhd2Z1bC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pg0KPj4+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPj4+PiAtIFRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBt YXkgY29udGFpbg0KPj4+PiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0 ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGll bnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVi bGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90 aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5 IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91 ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rp b24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBh dXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo+Pj4+DQo+Pj4+DQo+Pj4NCj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4+PiBUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50 cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVy aWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50 IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1Ymxp YyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhl ciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBy ZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIg c3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9u IG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0 aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0KPj4+DQo+Pj4NCj4+DQo+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+IFRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGlu Y2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3Ro ZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9y bWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4g dGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRv IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0u IFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhp cyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVk IGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo+Pg0KPj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRoaXMg dHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRl cmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJs ZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkg dXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVk IHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5z bWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2Vt aW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Np b24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUg dW5sYXdmdWwuDQo+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86 c2lwY29yZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55 IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZp bGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGlj aXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0 ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkg YW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGlt bWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9u IGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciBy ZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRz IGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KVGhp cyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1h dGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNh YmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFu eSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJh bnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNz ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlz c2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBi ZSB1bmxhd2Z1bC4K --_000_BBF5DDFE515C3946BC18D733B20DAD2338E3CD6EXMB104ADSrimnet_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGU+QGZvbnQtZmFjZSB7 Cglmb250LWZhbWlseTogQ2FsaWJyaTsKfQpAZm9udC1mYWNlIHsKCWZvbnQtZmFtaWx5OiBUYWhv bWE7Cn0KQHBhZ2UgV29yZFNlY3Rpb24xIHttYXJnaW46IDEuMGluIDEuMGluIDEuMGluIDEuMGlu OyB9ClAuTXNvTm9ybWFsIHsKCUZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7IE1BUkdJTjogMGluIDBpbiAwcHQKfQpMSS5Nc29Ob3JtYWwgewoJ Rk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsg TUFSR0lOOiAwaW4gMGluIDBwdAp9CkRJVi5Nc29Ob3JtYWwgewoJRk9OVC1TSVpFOiAxMnB0OyBG T05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsgTUFSR0lOOiAwaW4gMGluIDBw dAp9CkE6bGluayB7CglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUKfQpT UEFOLk1zb0h5cGVybGluayB7CglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxp bmUKfQpBOnZpc2l0ZWQgewoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxp bmUKfQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsKCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVD T1JBVElPTjogdW5kZXJsaW5lCn0KUC5lbWFpbHF1b3RlIHsKCUZPTlQtU0laRTogMTJwdDsgQk9S REVSLVRPUDogbWVkaXVtIG5vbmU7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IApSb21hbiIsInNl cmlmIjsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v bmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctVE9QOiAwaW47IFBBRERJTkctTEVGVDog MGluOyBNQVJHSU46IDBpbiAwaW4gMHB0IDFwdDsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQ QURESU5HLVJJR0hUOiAwaW4KfQpMSS5lbWFpbHF1b3RlIHsKCUZPTlQtU0laRTogMTJwdDsgQk9S REVSLVRPUDogbWVkaXVtIG5vbmU7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IApSb21hbiIsInNl cmlmIjsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v bmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctVE9QOiAwaW47IFBBRERJTkctTEVGVDog MGluOyBNQVJHSU46IDBpbiAwaW4gMHB0IDFwdDsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQ QURESU5HLVJJR0hUOiAwaW4KfQpESVYuZW1haWxxdW90ZSB7CglGT05ULVNJWkU6IDEycHQ7IEJP UkRFUi1UT1A6IG1lZGl1bSBub25lOyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyAKUm9tYW4iLCJz ZXJpZiI7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBu b25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLVRPUDogMGluOyBQQURESU5HLUxFRlQ6 IDBpbjsgTUFSR0lOOiAwaW4gMGluIDBwdCAxcHQ7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsg UEFERElORy1SSUdIVDogMGluCn0KU1BBTi5FbWFpbFN0eWxlMTkgewoJRk9OVC1GQU1JTFk6ICJD YWxpYnJpIiwic2Fucy1zZXJpZiI7IENPTE9SOiAjMWY0OTdkCn0KLk1zb0NocERlZmF1bHQgewoJ Rk9OVC1TSVpFOiAxMHB0Cn0KRElWLldvcmRTZWN0aW9uMSB7CgkKfQo8L3N0eWxlPjxzdHlsZSBp ZD0ib3dhUGFyYVN0eWxlIj5QIHsKCU1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLVRPUDogMHB4 Cn0KPC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIiBvY3NpPSIwIiBmcHN0eWxlPSIxIj4NCjxmb250IHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48YnI+DQpBZ3JlZWQ8YnI+DQo8L2ZvbnQ+PGJyPg0KJm5ic3A7 PGJyPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxiPkZyb208L2I+OiBDaHJpc3RlciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbV0NCjxicj4NCjxiPlNlbnQ8L2I+OiBGcmlkYXksIE9jdG9iZXIgMjUs IDIwMTMgMDI6MTEgUE0gQ2VudHJhbCBTdGFuZGFyZCBUaW1lPGJyPg0KPGI+VG88L2I+OiBBbmRy ZXcgQWxsZW47IFBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAYWx1bS5taXQuZWR1Jmd0OzsgU0lQ Q09SRSAmbHQ7c2lwY29yZUBpZXRmLm9yZyZndDsNCjxicj4NCjxiPlN1YmplY3Q8L2I+OiBSRTog W3NpcGNvcmVdIE5ldyBzaXBjb3JlIGRyYWZ0IHN1Ym1pc3Npb24gZHJhZnQtYWxsZW4tc2lwY29y ZS1zaXAtdHJlZS1jYXAtaW5kaWNhdG9ycw0KPGJyPg0KPC9mb250PiZuYnNwOzxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFRhaG9tYTsg Zm9udC1zaXplOiAxMHB0OyBkaXJlY3Rpb246IGx0cjsiPg0KPHA+SGksPC9wPg0KPGRpdj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTFwdDsiPiZuYnNwOzwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7IGZvbnQtc2l6ZTogMTFwdDsiPiZndDtJZiB0aGUgc2VtYW50aWMgb2YgZy54IGlz IGRlZmluZWQgYXMgdGhlIHN1cHBvcnQgZm9yIHRoZSBzZXNzaW9uIHRyYW5zZmVyIGNhcGFiaWxp dHkgYW5kIHRoZSBVUkkNCjxiPmF0IHRoZSBlbnRpdHk8L2I+IDxiPmluY2x1ZGluZyBpdDwvYj4g Zm9yIHNlbmRpbmcgcmVxdWVzdCB0byBpbnZva2U8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTog JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEx cHQ7Ij4mZ3Q7dGhlIHNlc3Npb24gdHJhbnNmZXIgJm5ic3A7dGhlbiB0aGUgc2lwIG1ldGhvZHMg YW5kIHNpcCBleHRlbnNpb25zIGFsc28gaW5jbHVkZWQgaW4gdGhlIEZlYXR1cmUtQ2FwcyBoZWFk ZXIgZmllbGQgYWxzbyBhcHBseSB0byB0aGUgVVJJIGZvciBzZXNzaW9uDQogdHJhbnNmZXIuPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMXB0OyI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1m YW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1z aXplOiAxMXB0OyI+RXZlbiBpZiB0aGUgc2VtYW50aWMgb2YgZy54IGV4cGxpY2l0bHkgc2F5cyB0 aGF0IHRoZSBhZGRyZXNzIHBvaW50cyB0byB0aGUgc2FtZSBlbnRpdHkgdGhhdCBpbmRpY2F0ZXMg c3VwcG9ydCBvZiB0aGUgZmVhdHVyZSwgSSBzdGlsbCB0aGluayB0aGUNCiBnLnggRkNJIHNwZWNp ZmljYXRpb24gc2hvdWxkIGRlc2NyaWJlIGhvdyBnLnggaXMgdXNlZCB0b2dldGhlciB3aXRoIG90 aGVyIEZDSXMgKGUuZy4gJiM0MztzaXAubWV0aG9kcykuDQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZh bWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNp emU6IDExcHQ7Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDExcHQ7Ij5UaGF0IHdp bGwgaGVscCBpbXBsZW1lbnRvcnMgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhleSBjYW4gaW5jbHVk ZSBnLnkgaW4gdGhlIHNhbWUgRmVhdHVyZS1DYXBzIGhlYWRlciBmaWVsZCBhcyBnLngmbmJzcDtv ciBub3QsIGlmIGcueSBhbHNvIHVzZXMgJiM0MztzaXAubWV0aG9kcy48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBm b250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBm b250LXNpemU6IDExcHQ7Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDExcHQ7Ij5S ZWdhcmRzLDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTFwdDsiPjwvc3Bhbj4mbmJzcDs8L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7IGZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7IGZvbnQtc2l6ZTogMTFwdDsiPkNocmlzdGVyPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6 ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAx MXB0OyI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMXB0OyI+Jm5ic3A7PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItd2lkdGg6IDFwdCBtZWRpdW0gbWVkaXVt OyBib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLWNvbG9yOiByZ2IoMTgxLCAx OTYsIDIyMykgY3VycmVudENvbG9yIGN1cnJlbnRDb2xvcjsgcGFkZGluZzogM3B0IDBpbiAwaW47 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7Ij4gQ2hyaXN0ZXIg SG9sbWJlcmcgW21haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDI1LCAyMDEzIDI6NDcgUE08YnI+DQo8Yj5Ubzo8 L2I+IFBhdWwgS3l6aXZhdDsgQW5kcmV3IEFsbGVuOyBTSVBDT1JFPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJFOiBbc2lwY29yZV0gTmV3IHNpcGNvcmUgZHJhZnQgc3VibWlzc2lvbiBkcmFmdC1hbGxl bi1zaXBjb3JlLXNpcC10cmVlLWNhcC1pbmRpY2F0b3JzPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5 bGU9ImNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7Ij5IaSw8L3NwYW4+PC9wPg0KPHA+PHNw YW4gc3R5bGU9ImNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7Ij4mbmJzcDs8L3NwYW4+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7Ij4mZ3Q7Jmd0 OyBUaGUgbmV4dCByZXZpc2lvbnMgd2lsbCBjb250YWluIG1vcmUgZGV0YWlscyBvbiB3aGF0IGVh Y2ggRkNJIChhcyBDaHJpc3RlciBub3cgY2FsbHMgdGhlbSBtZWFucykuPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyBJZiBzb21lIGFyZSBub3Qgd2VsbCB1bmRlcnN0b29kIEkgd2lsbCByZW1v dmUgdGhlbSBmcm9tIHRoZSBkcmFmdCAoaS5lLiBkcm9wJm5ic3A7IHRoZSByYXQgaG9sZXMpPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIHRoaW5rIG15IGVtYWlsIGV4Y2hhbmdlIHdpdGgg Q2hyaXN0ZXIgY2xhcmlmaWVzIHRoZSBvdGhlciBwb2ludHMuPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBEb2VzIHRoaXMgcmVwcmVzZW50IGluIHByaW5jaXBsZSBhIHdheSBmb3J3YXJkPzxi cj4NCiZndDs8YnI+DQomZ3Q7IE1heWJlLiBXZSdsbCBoYXZlIHRvIHNlZSBob3cgaXQgZ29lcy48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgY2hhbGxlbmdlIGlzLCBJIHRoaW5rLCB0aGF0IHlvdSB3 YW50IHRvIGJyaW5nIGluIGEgYnVuY2ggb2YgdGhlIDM4NDAgPGJyPg0KJmd0OyBmZWF0dXJlIHRh Z3MsIGFuZCBoYXZlIHRoZW0gbWVhbiBzb21ldGhpbmcgYWtpbiB0byB3aGF0IHRoZXkgZG8gYXMg PGJyPg0KJmd0OyBmZWF0dXJlIHRhZ3Mgd2hlbiB1c2VkIGFzIEZDSXMuIEJ1dCB0aGVyZSBuZWVk cyB0byBiZSBzb21lIHdheSB0byA8YnI+DQomZ3Q7IGRlc2NyaWJlIHdoYXQgKmVhY2gqIG9uZSBt ZWFucy4gSXQncyBub3QgaW1tZWRpYXRlbHkgY2xlYXIgdG8gbWUgaG93IHRvIDxicj4NCiZndDsg ZG8gdGhhdC48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgZm9udC1m YW1pbHk6ICZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNp emU6IDEwcHQ7Ij5BcyBJIHNhaWQgaW4gYW5vdGhlciByZXBseSwgSSB0aGluayB0aGF0IHRoZSBG Q0lzIHRoYXQgdXNlIHRoZSAmIzQzO3NpcC5tZXRob2QgZXRjIEZDSXMgbmVlZCB0byBkZXNjcmli ZSBob3cgdGhleSBhcmUgdXNlZCBpbiBjb25qdW5jdGlvbi48L3NwYW4+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7Ij4mbmJzcDs8L3NwYW4+PC9wPg0K PHA+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7Ij5FeGFtcGxlOjwv c3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyBmb250LWZhbWlseTogJnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsi PiZuYnNwOzwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyBmb250LWZh bWlseTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6 ZTogMTBwdDsiPkZlYXR1cmUtQ2FwczogKjsmIzQzO2cueDsmIzQzO3NpcC5tZXRob2RzPSZxdW90 O0lOVklURSZxdW90Ozwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyBm b250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZv bnQtc2l6ZTogMTBwdDsiPkZlYXR1cmUtQ2FwczogKjsmIzQzO2cueTsmIzQzO3NpcC5tZXRob2Rz PSZxdW90O0lOVklURSZxdW90Ozwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IGJs YWNrOyBmb250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7IGZvbnQtc2l6ZTogMTBwdDsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0i Y29sb3I6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsiPlRoZSBGQ0kgc3BlY2lmaWNhdGlvbnMgZm9y ICYjNDM7Zy54IGFuZCAmIzQzO2cueSZuYnNwO25lZWQgdG8mbmJzcDtkZXNjcmliZSBob3cgdGhl eSBhcmUgdXNlZCB0b2dldGhlciB3aXRoICYjNDM7c2lwLm1ldGhvZHMsIGlmIHRoZXJlIGlzIGEg cmVsYXRpb25zaGlwLjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyBm b250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZv bnQtc2l6ZTogMTBwdDsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6 IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsiPk90aGVyd2lzZSAmIzQzO3NpcC5tZXRob2RzIG9ubHkg bWVhbnMgdGhhdCB0aGUgZW50aXR5IHRoYXQgaW5zZXJ0ZWQgdGhlIEZDSXMgc3VwcG9ydCAmcXVv dDtJTlZJVEUmcXVvdDsuPC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7 IGZvbnQtZmFtaWx5OiAmcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozsg Zm9udC1zaXplOiAxMHB0OyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xv cjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsgZm9udC1zaXplOiAxMHB0OyI+UmVnYXJkcyw8L3NwYW4+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7Ij4mbmJzcDs8L3NwYW4+PC9wPg0K PHA+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7Ij5DaHJpc3Rlcjwv c3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyBmb250LWZhbWlseTogJnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsi PiZuYnNwOzwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyBmb250LWZh bWlseTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6 ZTogMTBwdDsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNr OyBmb250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 IGZvbnQtc2l6ZTogMTBwdDsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29s b3I6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cD48c3BhbiBz dHlsZT0iY29sb3I6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8 cD48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsiPiZndDsgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IFBhdWwgS3l6aXZhdCBbPGEgaHJl Zj0ibWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpw a3l6aXZhdEBhbHVtLm1pdC5lZHU8L2E+XTxicj4NCiZndDsgU2VudDogRnJpZGF5LCBPY3RvYmVy IDI1LCAyMDEzIDEwOjA2IEFNPGJyPg0KJmd0OyBUbzogQW5kcmV3IEFsbGVuOyA8YSBocmVmPSJt YWlsdG86R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+DQpH b256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb208L2E+PGJyPg0KJmd0OyBDYzogPGEgaHJlZj0i bWFpbHRvOnJsYkBpcHYuc3giIHRhcmdldD0iX2JsYW5rIj5ybGJAaXB2LnN4PC9hPjsgPGEgaHJl Zj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmFkYW1Abm9zdHJ1 bS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t IiB0YXJnZXQ9Il9ibGFuayI+DQpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+OyA8 YSBocmVmPSJtYWlsdG86bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij4NCm1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6 IE5ldyBzaXBjb3JlIGRyYWZ0IHN1Ym1pc3Npb24gZHJhZnQtYWxsZW4tc2lwY29yZS1zaXAtdHJl ZS1jYXAtaW5kaWNhdG9yczxicj4NCiZndDs8YnI+DQomZ3Q7IEFuZHJldyw8YnI+DQomZ3Q7PGJy Pg0KJmd0OyAoSSBzZWUgdGhpcyBpcyBzdGlsbCBvbiB0aGUgcHJpdmF0ZSB0aHJlYWQuIEknbGwg cmVwbHkgaGVyZSwgYnV0IHRoaXMgZXhjaGFuZ2Ugc2hvdWxkIHByb2JhYmx5IGJlIHJlcG9zdGVk IHRvIHRoZSBzaXBjb3JlIGxpc3QgYXMgcGFydCBvZiB0aGUgcHVibGljIGRpc2N1c3Npb24gb2Yg dGhlIGRyYWZ0Lik8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiAxMC8yNC8xMyAxMDo0MSBQTSwgQW5k cmV3IEFsbGVuIHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUGF1bDxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBhbSBoYXBweSB0byBkbyBhIHJldmlzaW9uIHdpdGggbW9y ZSBkZXRhaWxzIG9uIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGNhcGFiaWxpdHkgaW5kaWNhdG9ycy4g SG93ZXZlciBJIGRvbid0IHRoaW5rIGl0IHNob3VsZCBiZSBoZWxkIHRvIGEgdmVyeSBtdWNoIGhp Z2hlciBiYXIgdGhhbiB0aGUgZGV0YWlscyBpbiBSRkMgMzg0MCBhbmQgdGhlIG90aGVyIG1lZGlh IGZlYXR1cmUgdGFnIFJGQ3MgcmVnYXJkaW5nIHRoZSBtZWFuaW5nIG9mIHRob3NlDQogdGFncy48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBLZWVwIGluIG1pbmQgdGhhdCB0aGUgZHJpdmluZyBmb3JjZSBm b3IgdGhlIGRlZmluaXRpb24gb2YgZmVhdHVyZSB0YWdzIGluIDM4NDAgd2FzIGluIHN1cHBvcnQg b2YgY2FsbGVycHJlZnMgKDM4NDEpLiBTbyB0aGUgY29udGV4dCBmb3IgdGhlIHVzZSBvZiBmZWF0 dXJlIHRhZ3Mgd2FzIHRoYXQgdGhleSB3b3VsZCBiZSBwbGFjZWQgb24gQ29udGFjdHMgaW4gUkVH SVNURVIgcmVxdWVzdHMuIFNvIHlvdSBjYW4gaW50ZXJwcmV0IHRoZSBkZWZpbml0aW9ucw0KIGlu IHRoYXQgY29udGV4dDogdGhhdCBhIHJlcXVlc3Qgc2VudCB0byBhbiBBT1IgdXNpbmcgY2FsbGVy cHJlZnMgY2FuIGFmZmVjdCB0aGUgY2hvaWNlIG9mIHdoaWNoIGRldmljZSB0aGUgcmVxdWVzdCBn b2VzIHRvIGFjY29yZGluZyB0byB0aGUgY2FwYWJpbGl0aWVzIGl0IHdhbnRzLiBJbiB0aGF0IGNv bnRleHQgYXVkaW8sIHZpZGVvLCBpc2ZvY3VzIGFsbCBtYWtlIHNlbnNlLjxicj4NCiZndDs8YnI+ DQomZ3Q7IFRoZWlyIHVzZSBvbiBDb250YWN0cyBpbiBkaWFsb2dzIHdhcyBkZXJpdmF0aXZlIHRv IHRoYXQ6IGJlY2F1c2UgY2FsbGVycHJlZiBzdXBwb3J0IGlzIG9wdGlvbmFsLCB0aGVyZSBpcyBu byBndWFyYW50ZWUgdGhhdCB0aGUgZGV2aWNlIHlvdSByZWFjaCB2aWEgY2FsbGVycHJlZnMgd2ls bCBoYXZlIHRoZSBjYXBhYmlsaXRpZXMgeW91IHJlcXVlc3RlZC4gU28gdGhlIHZhbHVlcyBpbiB0 aGUgY29udGFjdCBoZWxwIGNvbmZpcm0gd2hhdCB5b3UgZ290Ljxicj4NCiZndDs8YnI+DQomZ3Q7 IE9mIGNvdXJzZSB0aGV5IGhhdmUgc2luY2UgYmVlbiB1c2VkIG90aGVyIHdheXMuIEFuZCB0aGUg ZGVzY3JpcHRpb25zIG9mIHRoZW0gZG9uJ3QgbmVjZXNzYXJpbHkgcmVmbGVjdCB0aGF0LiBJTU8g dGhhdCBpcyBhIGRlZmVjdCBkdWUgdG8gdGhlIGV2b2x1dGlvbiBvZiB1c2UuPGJyPg0KJmd0Ozxi cj4NCiZndDsgSSdtIGxvb2tpbmcgZm9yIHRoZSBzYW1lIHNvcnQgb2YgY29udGV4dCBmb3IgdXNl IHdpdGggdGhlIGZlYXR1cmUtY2Fwcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbiBwcml2YXRlIGRp c2N1c3Npb24geW91IGluZGljYXRlZCB0byBtZSB0aGF0IHlvdSBleHBlY3RlZCB0aGUgZmVhdHVy ZSBjYXBzIHRvIGJlIGdyb3VwZWQgLSB3aXRoIG9uZSBvZiB0aGVtIGdpdmluZyB0aGUgVVJJIG9m IHRoZSBkZXZpY2UgdGhhdCB0aGUgb3RoZXIgdGFncyBhcHBseSB0by4gSSBndWVzcyB0aGlzIHdv dWxkIGVuZCB1cCBsb29raW5nIHNvbWV0aGluZyBsaWtlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZlYXR1cmUtQ2FwczogKjtnLnVyaT0mcXVvdDs8YSBocmVm PSJzaXA6Zm9vQGV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2lwOmZvb0BleGFtcGxlLmNv bTwvYT4mcXVvdDs7YXVkaW88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZlYXR1 cmUtQ2FwczogKjtnLnVyaT0mcXVvdDs8YSBocmVmPSJzaXA6YmFyQGV4YW1wbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+c2lwOmJhckBleGFtcGxlLmNvbTwvYT4mcXVvdDs7YXVkaW87dmlkZW87aXNm b2N1czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmVhdHVyZS1DYXBzOiAqO2cu dXJpPSZxdW90OzxhIGhyZWY9InNpcDpiYXpAZXhhbXBsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5z aXA6YmF6QGV4YW1wbGUuY29tPC9hPiZxdW90Ozt0ZXh0PGJyPg0KJmd0Ozxicj4NCiZndDsgKEkn bSBtYWtpbmcgdXAgZy51cmkgZm9yIHRoZSBleGFtcGxlLik8YnI+DQomZ3Q7PGJyPg0KJmd0OyBB bmQgdGhlbiBwcmVzdW1hYmx5IHNvbWVib2R5IG9uIHRoZSBzaWduYWxpbmcgcGF0aCB3aWxsICZx dW90O3Nob3AmcXVvdDsgaW4gdGhlIGZlYXR1cmUgY2FwcyBmb3IgdGhlIGNhcGFiaWxpdGllcyBp dCB3YW50cywgYW5kIHRoZW4gc2VuZCBhIHJlcXVlc3QgdG8gdGhhdCBVUkksIHdpdGggdGhlIGV4 cGVjdGF0aW9uIHRoYXQgdGhlIFVBIHJlc3BvbmRpbmcgd2lsbCBoYXZlIHRob3NlIGNhcGFiaWxp dGllcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIHNlbWFudGljcyBzaG91bGQgYmUgbm8g ZGlmZmVyZW50IHRoYW4gdGhvc2Ugb2YmbmJzcDsgdGhlIGNvcnJlc3BvbmRpbmcgZXhpc3Rpbmcg bWVkaWEmbmJzcDsgZmVhdHVyZSB0YWcgaWYgaXQgaXMgcHJlc2VudCBpbiB0aGUgQ29udGFjdCBo ZWFkZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsgTm90ZSB0aGF0IDY4MDkgc2F5czo8YnI+DQomZ3Q7 PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaGVuIGEgU0lQIGVudGl0 eSByZWNlaXZlcyBhIFNJUCByZXF1ZXN0LCBvciByZXNwb25zZSwgdGhhdCBjb250YWluczxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb25lIG9yIG1vcmUgRmVhdHVyZS1D YXBzIGhlYWRlciBmaWVsZHMsIHRoZSBmZWF0dXJlLWNhcGFiaWxpdHk8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZGljYXRvcnMgaW4gdGhlIGhlYWRlciBmaWVsZCBp bmZvcm0gdGhlIGVudGl0eSBhYm91dCB0aGUgZmVhdHVyZXM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCBjYXBhYmlsaXRpZXMgc3VwcG9ydGVkIGJ5IGVudGl0aWVz IGluIHRoZSBTSVAgbWVzc2FnZSBzaWduYWxpbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHBhdGguJm5ic3A7IFRoZSBwcm9jZWR1cmUgYnkgd2hpY2ggZmVhdHVyZXMg YW5kIGNhcGFiaWxpdGllcyBhcmUgaW52b2tlZDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBh bmQgTVVTVCBiZSBkZXNjcmliZWQgYnk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGluZGl2aWR1YWwgZmVhdHVyZS1jYXBhYmlsaXR5IGluZGljYXRvciBzcGVjaWZpY2F0 aW9ucy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBB IEZlYXR1cmUtQ2FwcyBoZWFkZXIgZmllbGQgdmFsdWUgY2Fubm90IGNvbnZleSB0aGUgYWRkcmVz cyBvZiB0aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNJUCBlbnRp dHkgdGhhdCBpbnNlcnRlZCB0aGUgRmVhdHVyZS1DYXBzIGhlYWRlciBmaWVsZC4mbmJzcDsgSWY8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFkZGl0aW9uYWwgZGF0YSBh Ym91dCBhIHN1cHBvcnRlZCBmZWF0dXJlIG5lZWRzIHRvIGJlIGNvbnZleWVkLCBzdWNoPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcyB0aGUgYWRkcmVzcyBvZiB0aGUg U0lQIGVudGl0eSB0aGF0IGluZGljYXRlZCBzdXBwb3J0IG9mIHRoZTxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZmVhdHVyZSwgdGhlbiB0aGUgZmVhdHVyZSBkZWZpbml0 aW9uIG5lZWRzIHRvIGRlZmluZSBhIHdheSB0byBjb252ZXk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgaW5mb3JtYXRpb24gYXMgYSB2YWx1ZSBvZiB0aGUgYXNz b2NpYXRlZCBmZWF0dXJlLWNhcGFiaWxpdHk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGluZGljYXRvci48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIHdhcyBkaXNjdXNz ZWQgYXQgbGVuZ3RoIHdoaWxlIHRoYXQgUkZDIHdhcyB1bmRlciBjb25zaWRlcmF0aW9uLiBZZXQg dGhlIGRlZmluaXRpb25zIG9mIHRoZSB0YWdzIGluICp0aGlzKiBkcmFmdCBkb24ndCBzcGVjaWZ5 IHRoYXQuPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSByZWdpc3RyYXRpb24gdGVtcGxhdGVz IGN1cnJlbnRseSByZWZlcmVuY2UgdGhlIFJGQyAzODQwIGFuZCB0aGUgb3RoZXIgUkZDcyB0aGF0 IGRlZmluZSB0aGUgb3RoZXIgbWVkaWEgZmVhdHVyZSB0YWdzIHRoYXQgY29ycmVzcG9uZCB0byB0 aGVzZSBmZWF0dXJlIGNhcGFiaWxpdHkgaW5kaWNhdG9ycy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBB bmQgdGhvc2UgZGVmaW5pdGlvbnMgd2VyZSB3cml0dGVuIHRvIGJlIHVuZGVyc3Rvb2QgaW4gdGhl IGNvbnRleHQgb2YgMzg0MC8zODQxLiBUaGV5IG1ha2Ugc2Vuc2UgaW4gdGhhdCBjb250ZXh0LCBi dXQgbm90IGluICp0aGlzKiBjb250ZXh0Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhdWw8YnI+DQomZ3Q7PGJyPg0KJmd0 OyZndDsgQnV0IGlmIG1vcmUgZXhwbGljaXQgZGV0YWlsIGlzIHJlcXVpcmVkIHRoZW4gSSBjYW4g YWRkIHNvbWUgbW9yZSB0ZXh0Jm5ic3A7IG9yIGFsdGVybmF0aXZlbHkgcmVtb3ZlIHRoZSBsZXNz IGltcG9ydGFudCBvbmVzIGlmIHRoZXkgYXJlIGdvaW5nIHRvIGJlY29tZSByYXQgaG9sZXMuIFRo ZSBvbmVzIEkgcmVnYXJkIGFzIHJlYWxseSBpbXBvcnRhbnQgYW5kIHVyZ2VudCBhcmUgc2lwLm1l dGhvZHMsIHNpcC5leHRlbnNpb25zIGFuZCBzaXAuZXZlbnRzDQogdGhlIG1lYW5pbmcgb2Ygd2hp Y2ggSSB0aGluayBzaG91bGQgYmUgcXVpdGUgY2xlYXIuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBBbmRyZXc8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiBQYXVsIEt5eml2YXQgWzxhIGhyZWY9Im1h aWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cGt5eml2 YXRAYWx1bS5taXQuZWR1PC9hPl08YnI+DQomZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgT2N0b2Jl ciAyNCwgMjAxMyAwNDo0NCBQTSBDZW50cmFsIFN0YW5kYXJkIFRpbWU8YnI+DQomZ3Q7Jmd0OyBU bzogQW5kcmV3IEFsbGVuOyA8YSBocmVmPSJtYWlsdG86R29uemFsby5DYW1hcmlsbG9AZXJpY3Nz b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+DQpHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb208 L2E+PGJyPg0KJmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpHb256YWxvLkNhbWFyaWxsb0Bl cmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5Hb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5j b208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86cmxiQGlwdi5zeCIg dGFyZ2V0PSJfYmxhbmsiPnJsYkBpcHYuc3g8L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86cmxiQGlw di5zeCIgdGFyZ2V0PSJfYmxhbmsiPnJsYkBpcHYuc3g8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0 bzphZGFtQG5vc3RydW0uY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhbUBub3N0cnVtLmNvbTwvYT4g Jmx0OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRh bUBub3N0cnVtLmNvbTwvYT4mZ3Q7Ozxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9hPiZndDs7PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOm1hcnkuaWV0Zi5i YXJuZXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5j b208L2E+ICZsdDs8YSBocmVmPSJtYWlsdG86bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5tYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbTwvYT4mZ3Q7OyBQYXVsIEt5 eml2YXQ8YnI+DQomZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBreXppdmF0QGFsdW0ubWl0 LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPnBreXppdmF0QGFsdW0ubWl0LmVkdTwvYT4mZ3Q7PGJyPg0K Jmd0OyZndDsgU3ViamVjdDogUmU6IE5ldyBzaXBjb3JlIGRyYWZ0IHN1Ym1pc3Npb248YnI+DQom Z3Q7Jmd0OyBkcmFmdC1hbGxlbi1zaXBjb3JlLXNpcC10cmVlLWNhcC1pbmRpY2F0b3JzPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiAxMC8yNC8xMyA0OjA3IFBNLCBBbmRyZXcgQWxsZW4g d3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFBhdWw8YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT2s8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsgU28gd2UgYXJlIGJhc2ljYWxseSB3aGVyZSBJIHRob3VnaHQgd2Ugd2VyZSBhdCB3 aGVuIEkgc3VibWl0dGVkIHRoZSBkcmFmdC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsgTWF5YmUgeW91LCBBZGFtLCBHb256YWxvLCBSaWNoYXJkLCBDaHJpc3RlciBhbmQgSSAo cGx1cyBhbnlvbmUgZWxzZSB3aG8gaW5kaWNhdGVzIGludGVyZXN0KSBjYW4gaGF2ZSBzb21lIG9m ZmxpbmUgZGlzY3Vzc2lvbiBpbiBWYW5jb3V2ZXIgb24gd2hldGhlciBhbmQgaG93IHRvIHByb2dy ZXNzIHRoaXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBcyBJIGluZGljYXRlZCBhZ2Fp biBvbiB0aGUgc2lwY29yZSBsaXN0LCBJIGZvdW5kIHRoZSB0aGF0IHRoZSBkcmFmdDxicj4NCiZn dDsmZ3Q7IGRpZG4ndCBleHBsYWluIG5lYXJseSBlbm91Z2ggdG8gYWxsb3cgbWVhbmluZ2Z1bCB1 c2Ugb2YgdGhlc2UuPGJyPg0KJmd0OyZndDsgSSBrbm93IHlvdSByZXBsaWVkLCBhbmQgSSB3aWxs IGNvbnRpbnVlIHRoZSBjb252ZXJzYXRpb24gdGhlcmUuPGJyPg0KJmd0OyZndDsgQnV0IEkgd2ls bCBiZSBvcHBvc2VkIHRvIHRoZXNlIHVudGlsIGFuZCB1bmxlc3MgdGhlIGRyYWZ0IChhbmQgbm90 YWJseTxicj4NCiZndDsmZ3Q7IHRoZSBkZXNjcmlwdGlvbnMgb2YgdGhlIHRhZ3MpIGFyZSBjbGVh ciBhYm91dCBob3cgb25lIGNvdWxkIGZpZ3VyZSBvdXQ8YnI+DQomZ3Q7Jmd0OyB3aGF0IGNhbiBk byBpbiB0aGUgcHJlc2VuY2Ugb2YgdGhlIHRhZ3MgdGhhdCBvbmUgY291bGRuJ3QgZG8gd2l0aG91 dDxicj4NCiZndDsmZ3Q7IHRoZW0uIEFORCwgdGhhdCB0aGUgYmVoYXZpb3IgdGhhdCBzdWdnZXN0 cyBkb2Vzbid0ICZxdW90O2JyZWFrJnF1b3Q7IHNpcC4gKEUuZy4sPGJyPg0KJmd0OyZndDsgYnkg YWR2b2NhdGluZyBhIG5ldyBhbmQgaW5jb21wYXRpYmxlIHdheSB0byBkbyBzb21ldGhpbmcuKTxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2UgY2FuIGNvbnRpbnVlIHRoaXMgb24gdGhlIHNp cGNvcmUgbGlzdC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBQYXVsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg QW5kcmV3PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IC0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsgRnJvbTogUGF1bCBLeXppdmF0IFs8YSBo cmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRv OnBreXppdmF0QGFsdW0ubWl0LmVkdTwvYT5dPGJyPg0KJmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJz ZGF5LCBPY3RvYmVyIDI0LCAyMDEzIDAyOjU0IFBNIENlbnRyYWwgU3RhbmRhcmQgVGltZTxicj4N CiZndDsmZ3Q7Jmd0OyBUbzogQW5kcmV3IEFsbGVuOyBHb256YWxvIENhbWFyaWxsbyAmbHQ7PGEg aHJlZj0ibWFpbHRvOkdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPkdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7IENjOiBSaWNoYXJkIEJhcm5lcyAoPGEgaHJlZj0ibWFpbHRvOnJsYkBpcHYuc3giIHRhcmdl dD0iX2JsYW5rIj5ybGJAaXB2LnN4PC9hPikgJmx0OzxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4 IiB0YXJnZXQ9Il9ibGFuayI+cmxiQGlwdi5zeDwvYT4mZ3Q7OyBBZGFtIFJvYWNoPGJyPg0KJmd0 OyZndDsmZ3Q7ICg8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmFkYW1Abm9zdHJ1bS5jb208L2E+KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1 bS5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGFtQG5vc3RydW0uY29tPC9hPiZndDs7IENocmlzdGVy IEhvbG1iZXJnPGJyPg0KJmd0OyZndDsmZ3Q7ICg8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPC9hPikgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208 L2E+Jmd0Ozs8YnI+DQomZ3Q7Jmd0OyZndDsgTWFyeSBCYXJuZXMgKDxhIGhyZWY9Im1haWx0bzpt YXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnkuaWV0Zi5iYXJu ZXNAZ21haWwuY29tPC9hPikgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ5LmlldGYuYmFybmVzQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPC9hPiZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IE5ldyBzaXBjb3JlIGRyYWZ0IHN1Ym1p c3Npb248YnI+DQomZ3Q7Jmd0OyZndDsgZHJhZnQtYWxsZW4tc2lwY29yZS1zaXAtdHJlZS1jYXAt aW5kaWNhdG9yczxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBPbiAxMC8yNC8x MyAyOjE3IFBNLCBBbmRyZXcgQWxsZW4gd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBQYXVs PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhhdCBpcyBmaW5l LiBBbHRob3VnaCBNYXJ5IGluIGhlciByZXBseSB0byBtZSBzZWVtZWQgdG8gaW5kaWNhdGUgbWF5 YmUgdGhlcmUgd2FzIGEgcG9zc2liaWxpdHkgdG8gdXNlIHNvbWUgb2YgdGhlIERJU1BBVENIIHNw YXJlIHRpbWUgZm9yIGEgU0lQQ09SRSBzZXNzaW9uIGZvciB0aGlzLiBJcyB0aGF0IGEgcG9zc2li aWxpdHk/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSSBhbHJl YWR5IHJlcGxpZWQgdG8geW91ciBwb3N0PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7IEkgZGlzY3Vzc2VkIHRoYXQgd2l0aCBBZGFtLiBXZSBkZWNpZGVkIHdlIGNhbid0IHNldCBh IHByZWNlZGVudCB0bzxicj4NCiZndDsmZ3Q7Jmd0OyBzcGluIHVwIGEgc2Vzc2lvbiB0byBkaXNj dXNzIGEgZHJhZnQgdGhhdCBoYXNuJ3QgaGFkIHN1YnN0YW50aWFsPGJyPg0KJmd0OyZndDsmZ3Q7 IChhbnkpIGxpc3QgZGlzY3Vzc2lvbi48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsgQnV0IGxpc3QgZGlzY3Vzc2lvbiBpcyBhbHdheXMgd2VsY29tZS48YnI+DQomZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU29ycnks PGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhdWw8YnI+ DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEFuZHJldzxicj4NCiZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBQYXVsIEt5eml2YXQgWzxhIGhyZWY9Im1haWx0 bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cGt5eml2YXRA YWx1bS5taXQuZWR1PC9hPl08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBP Y3RvYmVyIDI0LCAyMDEzIDE6MzEgUE08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBBbmRyZXcg QWxsZW47IEdvbnphbG8gQ2FtYXJpbGxvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBDYzogUmljaGFy ZCBCYXJuZXMgKDxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4IiB0YXJnZXQ9Il9ibGFuayI+cmxi QGlwdi5zeDwvYT4pOyBBZGFtIFJvYWNoICg8YSBocmVmPSJtYWlsdG86YWRhbUBub3N0cnVtLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmFkYW1Abm9zdHJ1bS5jb208L2E+KTs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IENocmlzdGVyIEhvbG1iZXJnICg8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9hPik8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBOZXcgc2lwY29y ZSBkcmFmdCBzdWJtaXNzaW9uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdC1hbGxlbi1zaXBj b3JlLXNpcC10cmVlLWNhcC1pbmRpY2F0b3JzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgQW5kcmV3LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IEkgc3Bva2Ugd2l0aCBNYXJ5IGFib3V0IGl0LCBhbmQgd2UgY29uY2x1ZGVkIHRo YXQgZGlzcGF0Y2ggaXNuJ3QgcmlnaHQgZm9yIHRoaXMuIChJbiBhZGRpdGlvbiB0byBiZWluZyBj bGVhcmx5IHNpcGNvcmUsIGl0IGRpZG4ndCBtZWV0IHRoZSBkZWFkbGluZSBmb3IgZGlzcGF0Y2gu KSBJIHdhcyB3cm9uZyB0byBlbmNvdXJhZ2UgeW91IHRoYXQgd2F5Ljxicj4NCiZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFNvIG5vIG9mZmljaWFsIGxpdmUgZGlzY3Vzc2lv biBpbiBWYW5jb3V2ZXIuIChCdXQgaW5mb3JtYWw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGRpc2N1 c3Npb248YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGZpbmUuKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEknbGwgcmVzZW5kIG15IHByaXZhdGUgY29tbWVudHMgdG8g dGhlIHNpcGNvcmUgbGlzdCB0byBraWNrc3RhcnQgc29tZSBkaXNjdXNzaW9uIHRoZXJlLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFBhdWw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbiAx MC8yNC8xMyAxOjAxIFBNLCBBbmRyZXcgQWxsZW4gd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgSSBqdXN0IGVtYWlsZWQgTWFyeSBhc2tpbmcgZm9yIGFnZW5kYSB0aW1lLiBTaG91bGQg SSBjYW5jZWwgdGhhdCByZXF1ZXN0Pzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBGcm9tOiBHb256YWxvIENhbWFyaWxsbyBbPGEgaHJlZj0ibWFpbHRvOkdv bnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpHb256 YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb208L2E+XTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI0LCAyMDEzIDE6MDAgUE08YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBUbzogUGF1bCBLeXppdmF0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2M6 IEFuZHJldyBBbGxlbjsgUmljaGFyZCBCYXJuZXMgKDxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4 IiB0YXJnZXQ9Il9ibGFuayI+cmxiQGlwdi5zeDwvYT4pOyBBZGFtIFJvYWNoPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgKDxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29tIiB0YXJnZXQ9 Il9ibGFuayI+YWRhbUBub3N0cnVtLmNvbTwvYT4pOyBDaHJpc3RlciBIb2xtYmVyZzxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7ICg8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PC9hPik8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogTmV3IHNpcGNvcmUg ZHJhZnQgc3VibWlzc2lvbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0LWFsbGVuLXNp cGNvcmUtc2lwLXRyZWUtY2FwLWluZGljYXRvcnM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhpIFBhdWwsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBnaXZlbiB0aGF0IHlvdSB0aGluayB0aGlzIGJl bG9uZ3MgdG8gU0lQQ09SRSwgSSBkbyBub3Qgc2VlIHRoZSBuZWVkIHRvIHJ1biBpdCB0aHJvdWdo IERJU1BBVENILiBQbGVhc2UsIHN0YXJ0IHRlY2huaWNhbCBkaXNjdXNzaW9ucyBvbiB0aGUgZHJh ZnQgb24gdGhlIFNJUENPUkUgbGlzdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEdvbnphbG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDIyLzEwLzIwMTMgOToxMSBQTSwgUGF1bCBLeXpp dmF0IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiAxMC8yMi8xMyAxOjAw IFBNLCBBbmRyZXcgQWxsZW4gd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBQYXVsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZvciByZXZpZXdpbmcgdGhlIGRyYWZ0IGFscmVhZHkg YW5kIGdpdmluZyBtZSBlYXJseSBmZWVkYmFjay48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNeSByZXNwb25zZXMgYmVs b3cgaW5saW5lIChwcmVwZW5kZWQgd2l0aCBbQUEpLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENhbiBJIGFzayB0aGUg QURzIHRvIGRldGVybWluZSBBU0FQIGlmIHRoaXMgbmVlZHMgdG8gZ28gdG88YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERJU1BBVENIIGZpcnN0IG9yIG5vdC4gQXMgb3V0bGluZWQg YmVsb3cgbXkgdmlldyBpcyB0aGF0IGl0IGlzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB1bm5lY2Vzc2FyeSBmb3IgZXZlcnkgbGl0dGxlIHRoaW5nIHRvIGdvIHRvIERJU1BBVENI IGFzIHRoaXMganVzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY3JlYXRlcyBh ZGRpdGlvbmFsIGRlbGF5IGFuZCBvdmVyaGVhZC4gSWYgaXQgaXMgdG8gYmUgZGlzY3Vzc2VkPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiBESVNQQVRDSCB0aGVuIEkgZGVmaW5p dGVseSB3b3VsZCB3YW50IGFnZW5kYSB0aW1lIGF0SUVURiM4OCBmb3IgdGhpcy48YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGF2aW5n IG5vdyBzZWVuIEFuZHJldydzIHJlc3BvbnNlcyB0byBteSBpbml0aWFsIHF1ZXN0aW9ucywgSTxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGluayB0aGlzPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7ICpuZWVkcyogdG8gYmUgY2FyZWZ1bGx5IGNvbnNpZGVyZWQgYnkgc2lwY29y ZS4gSU1PIHRoaXMgaGFzIHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwb3RlbnRp YWwgdG8gY3JlYXRlIGEgZGlhbGVjdCBvZiBzaXAgdGhhdCBpcyBpbmNvbXBhdGlibGUgd2l0aDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBub3JtYWwgdXNhZ2UuIChNYXliZSBJTVMgaGFz IGFscmVhZHkgZG9uZSB0aGF0LiBCdXQgdGhpcyB3aWxsIG1ha2U8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgaXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd29yc2UuKTxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBC dXQgaWYgdGhlcmUgaXMgYSBkZXNpcmUgdG8gZGlzY3VzcyBpdCBwdWJsaWNseSBpbiBWYW5jb3V2 ZXIgdGhlbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkaXNwYXRjaCBpcyB0aGUgb3Bw b3J0dW5pdHkgYW5kIHNvIHNvbWUgZGlzY3Vzc2lvbiBvbiB0aGUgZGlzcGF0Y2g8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGlzdCBpbiBhZHZhbmNlIG9mIHRoYXQgd291bGQgYmUgYXBw cm9wcmlhdGUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IEknbGwgZGVmZXIgdG8gdGhlIEFEcyBvbiB0aGlzLjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNb3JlIGlubGlu ZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEFuZHJldzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tOiBQYXVsIEt5eml2YXQgWzxhIGhy ZWY9Im1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86 cGt5eml2YXRAYWx1bS5taXQuZWR1PC9hPl08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjIsIDIwMTMgMTA6MzMgQU08YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBBbmRyZXcgQWxsZW47IFJpY2hhcmQgQmFybmVzICg8 YSBocmVmPSJtYWlsdG86cmxiQGlwdi5zeCIgdGFyZ2V0PSJfYmxhbmsiPnJsYkBpcHYuc3g8L2E+ KTsgR29uemFsbyBDYW1hcmlsbG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICg8 YSBocmVmPSJtYWlsdG86R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9i bGFuayI+R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tPC9hPik7IEFkYW0gUm9hY2ggKDxh IGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhbUBub3N0 cnVtLmNvbTwvYT4pPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBS ZTogTmV3IHNpcGNvcmUgZHJhZnQgc3VibWlzc2lvbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZHJhZnQtYWxsZW4tc2lwY29yZS1zaXAtdHJlZS1jYXAtaW5kaWNhdG9yczxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEFuZHJldyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBhIGxlZ2FsaXN0aWMgbm90ZSwgaXRzIHF1ZXN0 aW9uYWJsZSB0byBtZSB3aGV0aGVyIHRoaXMga2luZCBvZjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgYWN0aW9uIGZhbGxzIHdpdGhpbiB0aGUgc2NvcGUgb2Ygc2lwY29yZS4gT1RP SCwgYW1vbmcgZXhpc3Rpbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdncywg c2lwY29yZSBpcyBwcm9iYWJseSB0aGUgYmVzdCBzdWl0ZWQgdG8gZGlzY3VzcyB0aGUgcHJvcG9z YWwuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXZSBjb3VsZCB0YWtlIGl0IHRv IERJU1BBVENILiBJIHRoaW5rIERJU1BBVENIIGhhcyBleHRyYSB0aW1lIGluPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpdHMgYWdlbmRhIGZvciBWYW5jb3V2ZXIsIHNvIHRoYXQg bWlnaHQgYmUgb25lIG9wdGlvbiBmb3IgeW91Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgQnV0IHRoZW4gSSBkb24ndCBrbm93IHdoZXJlIGRpc3BhdGNoIHdvdWxkIGRpc3BhdGNo IGl0LiBJdCBtYXkgYmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQgQUQg c3BvbnNvcmVkIGlzIHRoZSBiZXN0IHdheSB0byBnby48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbQUFdIEl0IHNlZW1l ZCB0byBtZSB0aGF0IHNpcGNvcmUgd2FzIHRoZSByaWdodCBwbGFjZS4gVGhpcyBkcmFmdDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVnaXN0ZXJzIGZlYXR1cmUtY2FwYWJpbGl0 eSBpbmRpY2F0b3JzIGluIGEgcmVnaXN0cnkgdGhhdCB3YXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGNyZWF0ZWQgYnkgYSBzaXBjb3JlIFJGQyAoUkZDIDY4MDkpLiBZb3UgY291 bGQgaW4gbXkgdmlldyBtYWtlIGFuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBh cmd1bWVudCB0aGF0IHRoaXMgc2hvdWxkIGV2ZW4gaGF2ZSBiZWVuIGRvbmUgYXMgcGFydCBvZiBS RkMgNjgwOS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgSWYgdGhpcyB3YXMganVzdCBhIG1hdHRlciBvZiByZWdpc3RlcmluZyBzb21l IG5ldyBmZWF0dXJlIGNhcHM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCB3ZXJl IG5vdCBjb250cm92ZXJzaWFsLCB0aGVuIEkgZG9uJ3QgdGhpbmsgc2lwY29yZSBuZWVkcyB0byBi ZSBpbnZvbHZlZC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgQnV0IGFzIEkgbWVudGlvbmVkIGFib3ZlLCBJIGRvIGNvbnNpZGVyIHRo ZXNlIGNvbnRyb3ZlcnNpYWwuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBEaXNjdXNzaW5nIGl0IG5vdyBvbiB0aGUgZGlzcGF0 Y2ggbGlzdCB3b3VsZCBiZSBhIGdvb2Qgc3RhcnQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRvd2FyZCBkaXNjdXNzaW5nIGl0IGF0IHRoZSBkaXNwYXRjaCBzZXNzaW9uLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IFtBQV0gQ2FuIEkgYXNrIHRoZSBBRHMgdG8gZGV0ZXJtaW5lIGlmIHRoaXMgbmVlZHMg dG8gZ28gdG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERJU1BBVENIIGZpcnN0 IG9yIG5vdC4gTXkgdmlldyBpcyB0aGF0IGl0IGlzIHVubmVjZXNzYXJ5IGZvcjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZXZlcnkgbGl0dGxlIHRoaW5nIHRvIGdvIHRvIERJU1BB VENIIGFzIHRoaXMganVzdCBjcmVhdGVzIGFkZGl0aW9uYWwgZGVsYXkgYW5kIG92ZXJoZWFkLjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBqdXN0IHJlZ2lzdGVycyBzb21l IGluZGljYXRvcnMgaW4gYW4gZXhpc3RpbmcgSUFOQSByZWdpc3RyeTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgYW5kIGlzIG5vdCAob3Igc2hvdWxkIG5vdCBiZSBJTUhPKSBhIG1h am9yIHByb2plY3QuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IFRvIG1lIHRoaXMgaXMgYSBtYXR0ZXIgb2Ygd2hldGhlciB5b3Ugd2Fu dCB0byBiZSBvcHBvcnR1bmlzdGljLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB0 aGlzIHdlbnQgdG8gZGlzcGF0Y2ggSSB3b3VsZCBub3cgcmVjb21tZW5kIHRoYXQgaXQgYmU8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZGlzcGF0Y2hlZCB0byBzaXBjb3JlLiBTbyBpdHMg YSBtYXR0ZXIgb2Ygd2hldGhlciB5b3Ugd2FudCB0byB0YWxrPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGFib3V0IGl0IGluIHRoZSBkaXNwYXRjaCBtZWV0aW5nLjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUmVnYXJk aW5nIHN1YnN0YW5jZSwgdGhpcyBkcmFmdCB0cm91YmxlcyBtZS4gSXQgdGFrZXM8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZlYXR1cmUtY2FwcyBpbiBleGFjdGx5IHRoZSBkaXJl Y3Rpb24gdGhhdCBJIGZvdW5kIG1vc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGNvbmNlcm5pbmcgYWJvdXQgdGhlIG1lY2hhbmlzbSBpbiB0aGUgZmlyc3QgcGxhY2UuPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgWW91ciBkcmFmdCBwYXJ0aXRpb25zIHRoZSBleGlzdGluZyBtZWRpYSBmZWF0dXJlIHRh Z3MgaW50byB0d288YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNldHM8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0gdGhvc2UgdGhhdCB3b3VsZCBiZSB1c2VmdWwg YXMgZmVhdHVyZS1jYXBhYmlsaXR5LWluZGljYXRvcnMsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBhbmQgdGhvc2UgdGhhdCBhcmVuJ3QuIEJ1dCBJIHNlZSBubyBleHBsYW5hdGlv biBvZiB0aGUgY3JpdGVyaWE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHVzZWQg dG8gbWFrZSB0aGlzIGRpc3RpbmN0aW9uLCBub3IgY2FuIEkgdGhpbmsgb2Ygb25lLjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFtBQV0gSSBiYXNlZCB0aGlzIGRlY2lzaW9uIG9uIHRoZSBmb2xsb3dpbmcgY3JpdGVyaWE6 IElmIGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZlYXR1cmUgdGFnIHdhcyBw b3RlbnRpYWxseSBhdCBhbGwgdXNlZnVsIGZvciBhbiBpbnRlcm1lZGlhcnkgdG88YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluZGljYXRlIGl0IHRoZW4gaW5jbHVkZSBpdCBpbiB0 aGUgcmVnaXN0cnkuIFRoZSBvbmVzIG5vdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgaW5jbHVkZWQgYXJlIGVpdGhlciBkaXJlY3RseSBhc3NvY2lhdGVkIHdpdGggdGhlIHVzZXI8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IChpbnRlcm1lZGlhcmllcyBhcmUgbm90 Jm5ic3A7IGRpcmVjdGx5IGFzc29jaWF0ZWQgd2l0aCB0aGUgdXNlcikgb3I8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdvdWxkIG9ubHkgZXZlciBoYXZlIG9uZSB2YWx1ZSAoZS5n IGF1dG9tYXRhKS4mbmJzcDsgSSBhbSBub3Qgc3VyZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgdGhhdCBldmVyeSBmZWF0dXJlLWNhcGFiaWxpdHkgaW5kaWNhdG9yIHByb3Bvc2Vk IHRvIGJlIHJlZ2lzdGVyZWQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIGFj dHVhbGx5IHVzZWZ1bCBidXQgdGhlbiBJIGRvbid0IHRoaW5rIGV2ZXJ5IG1lZGlhIGZlYXR1cmUg dGFnPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWdpc3RlcmVkIGJ5IFJGQyAz ODQwIGlzIGVpdGhlciAoSSBkb3VidCB2ZXJ5IG11Y2ggaWYgdGhlcmUgYXJlPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbXBsZW1lbnRhdGlvbiB1c2luZyB0aGUgc2lwLmFwcGxp Y2F0aW9uIG9yIHNpcC5jb250cm9sIGZlYXR1cmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRhZ3MpLiBJIGRvbid0IHRoaW5rIFJGQyAzODQwIGdvZXMgaW50byBhIGxvdCBvZiBk ZXRhaWxzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBqdXN0aWZ5aW5nIG9mIGV2 ZXIgcmVnaXN0ZXJlZCBtZWRpYSBmZWF0dXJlIHRhZyBhbmQgc3BlY2lmeWluZzxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGRldGFpbHMgb2YgaG93IHRoZXkgd291bGQgYmUg dXNlZCBlaXRoZXIuJm5ic3A7IEkgYW0gd2lsbGluZyB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgcmVtb3ZlIGFueSBmZWF0dXJlLWNhcGFiaWxpdHkgaW5kaWNhdG9ycyB0aGF0 IGFyZSBjb250cm92ZXJzaWFsIGV4Y2VwdCB0aGF0IEkgdGhpbmsgd2UgZGVmaW5pdGVseSBuZWVk IHNpcC5leHRlbnNpb25zLCBzaXAubWV0aG9kcyBhbmQgc2lwLmV2ZW50cy48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZXJlIGlzIGEgc2lnbmlmaWNhbnQgb3ZlcmhlYWQgdG8g d3JpdGluZyBhbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkIHByb2dyZXNzaW5nIGlu dGVybmV0IGRyYWZ0cyBzbyBteSB2aWV3IGlzIGxldHMgcmVnaXN0ZXIgYWxsIHRoYXQ8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWlnaHQgYmUgcmVtb3RlbHkgdXNlZnVsIGluIHRoZSBz YW1lIGRvY3VtZW50Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUganVkZ2VtZW50IG9mICZxdW90O3VzZWZ1bCZxdW90OyBpcyBy ZWFzb25hYmxlLiBCdXQgSSBzdGlsbCBjYW4ndCBkaXNjZXJuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHdoYXQgdGhlIHVzZSBpcyBmcm9tIHRoZSBpYW5hIHJlZ2lzdHJhdGlvbiBkZXNj cmlwdGlvbnMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBGb3IgdGhlIG9uZXMgdGhhdCB5b3UgaGF2ZSByZXF1ZXN0ZWQgZmVh dHVyZSBjYXBhYmlsaXR5PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbmRpY2F0 b3JzLCBJIGNhbm5vdCBmaWd1cmUgb3V0IHdoYXQgdXNpbmcgdGhlbSB3b3VsZCBtZWFuLiBGb3I8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGV4YW1wbGUsIHdoZW4gSSBzZWUgaXNG b2N1cyBvbiBhIENvbnRhY3QgaGVhZGVyIEkga25vdyBJIGFtIGluIGE8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbmZlcmVuY2UsIGFuZCB0aGF0IEkgY2FuIHN1YnNjcmliZSB0 byB0aGUgY29uZmVyZW5jZSBldmVudDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg cGFja2FnZSBhdCB0aGUgY29udGFjdCBVUkkuIElmIEkgc2VlIGlzRm9jdXMgaW4gYSBGZWF0dXJl LUNhcHMgaGVhZGVyLCB3aGF0IGRvZXMgaXQgbWVhbj88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFdoYXQgY2FuIEkgZG8gb25jZSBJIGtub3cgdGhpcz88YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZWN0 aW9uIDUuMTQgb2YgdGhpcyBkcmFmdCBzYXlzOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFRoaXMgRmVhdHVyZS1jYXBhYmlsaXR5IGluZGljYXRvciBpbmRpY2F0ZXMgdGhhdCB0aGUg aW50ZXJtZWRpYXJ5PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBpcyBhIGNvbmZlcmVuY2Ugc2VydmVyLCBhbHNvIGtub3duIGFzIGEgZm9jdXMs IGFuZCBpcyBjYXBhYmxlIG9mPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBtaXhpbmcgdG9nZXRoZXIgdGhlIG1lZGlhIGZvciBhbGwgY2FsbHMg dG8gdGhlIHNhbWUgVVJJLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLi4uPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBFeGFtcGxlcyBvZiB0eXBpY2FsIHVzZTogQSBjb25mZXJlbmNlIGJyaWRn ZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5kaWNhdGluZyB0aGF0IGl0PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBpcyBhIGNvbmZlcmVuY2UgYnJpZGdlIGFuZCBpcyBjYXBhYmxlIG9mIGFj dGluZyBhczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYSBjb25mZXJlbmNlPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBmb2N1cyBmb3IgdGhpcyBzZXNzaW9uLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFtBQV0gdGhl IHByZXNlbmNlIG9mIGlzZm9jdXMgaW4gYSBGZWF0dXJlLUNhcHMgaGVhZGVyIGZpZWxkIG1lYW5z PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0IGEgVUEgY2FuIGluaXRpYXRl IGEgY29uZmVyZW5jZSBieSBzZW5kaW5nIGEgUkVGRVIgcmVxdWVzdCB0bzxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIGludGVybWVkaWFyeSB0byBpbnZpdGUgYW5vdGhlciB1 c2VyIGFuZCBjcmVhdGUgYSBtdWx0aSB1c2VyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBjb25mZXJlbmNlIGZyb20gdGhlIDEtMSBzZXNzaW9uLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE5vdGUgdGhh dCBGZWF0dXJlLUNhcHMgZG9lc24ndCBpbmRpY2F0ZSB3aGljaCBlbnRpdHkgaGFzIHRoaXM8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNhcGFiaWxpdHksIG9ubHkgdGhhdCBzb21l dGhpbmcgZG9lcy4gQW5kIHNpbmNlIHRoaXMgd291bGQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHByZXN1bWFibHkgb25seSBiZSB1c2VkIGlmIGl0IHdhc24ndCB0aGUgVUFDIG9m IHRoZSByZXF1ZXN0LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VuZGluZyBh IHN1YnNjcmliZSB0byB0aGUgY29udGFjdCBhZGRyZXNzIG9mIHRoZSBVQUMgd291bGRuJ3QgbWFr ZSBzZW5zZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbQUFdIFllcyB0aGUgR1JVVSBvZiB0aGUgaW50ZXJtZWRpYXJ5 IHdvdWxkIGJlIG5lZWRlZCBidXQgSTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Y29uc2lkZXIgdGhpcyBhcHBsaWNhdGlvbiBzcGVjaWZpYyBhbmQgc28gdGhpcyB3b3VsZCBiZSBp bmNsdWRlZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW4gYSBmZWF0dXJlIHRh ZyByZWdpc3RlcmVkIGluIHRoZSBnbG9iYWwgdHJlZSBhcyBzdGF0ZWQgaW4gdGhlPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdCAmcXVvdDtSRkMgNjgwOSBbMV0gcHJvdmlk ZXMgdGhhdCBhZGRyZXNzZXMgb2YgaW50ZXJtZWRpYXJpZXMgY2FuPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBiZSBjb21tdW5pY2F0ZWQgYXMgYSB2YWx1ZSBvZiBhbiBhc3NvY2lh dGVkIGZlYXR1cmUtY2FwYWJpbGl0eTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg aW5kaWNhdG9yIHNvIGl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRvIGRlZmluZSBmZWF0dXJlIGNh cGFiaWxpdHk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluZGljYXRvcnMgYXMg cGFydCBvZiB0aGUgZ2xvYmFsIHRyZWUgdG8gY29tbXVuaWNhdGUgdGhlIEdSVVUgb2Y8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBpbnRlcm1lZGlhcnkgYW5kIGhlbmNlIHRo aXMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZG9jdW1lbnQuJnF1b3Q7Jm5ic3A7IC0gUkZDIDY4MDkgc3RhdGVzICZxdW90OyBJ ZiBhZGRpdGlvbmFsIGRhdGEgYWJvdXQgYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgc3VwcG9ydGVkIGZlYXR1cmUgbmVlZHMgdG8gYmUgY29udmV5ZWQsIHN1Y2ggYXMgdGhlIGFk ZHJlc3Mgb2Y8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBTSVAgZW50aXR5 IHRoYXQgaW5kaWNhdGVkIHN1cHBvcnQgb2YgdGhlIGZlYXR1cmUsIHRoZW4gdGhlPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmZWF0dXJlIGRlZmluaXRpb24gbmVlZHMgdG8gZGVm aW5lIGEgd2F5IHRvIGNvbnZleSB0aGF0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBpbmZvcm1hdGlvbiBhcyBhIHZhbHVlIG9mIHRoZSBhc3NvY2lhdGVkIGZlYXR1cmUtY2FwYWJp bGl0eTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5kaWNhdG9yLiZxdW90OyBI b3dldmVyIEkgdGhpbmsgdGhlIFNJUCBzcGVjaWZpYyBjYXBhYmlsaXR5PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbmRpY2F0b3JzIHN1Y2ggYXMgbWV0aG9kcywgZXh0ZW5zaW9u cyBhbmQgZXZlbnRzIHNob3VsZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXBw cm9wcmlhdGVseSBiZSByZWdpc3RlcmVkIGluIHRoZSBTSVAgdHJlZSBub3QgYXMgcHJvcHJpZXRh cnk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluZGljYXRvcjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzIGluIHRoZSBnbG9iYWwgdHJlZS48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU28geW91IGhhdmUg ZGVmaW5lZCBhIHNpcCB0cmVlIGZlYXR1cmUgdGFnIHRoYXQgaXMgb25seSB1c2VmdWwgaW48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uanVuY3Rpb24gd2l0aCBhbm90aGVyIGZlYXR1 cmUgdGFnIGZyb20gdGhlIGdsb2JhbCB0cmVlLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBBbmQgdGhlIGRlc2NyaXB0aW9uIG9mIHRoaXMgZmVhdHVyZSB0YWcgZG9lc24ndCBldmVuIG1l bnRpb24gdGhhdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgQW5kIHRoaXMgYWxsIGltcGxpZXMgYSBjb21wbGV0ZWx5IG5vbi1zdGFu ZGFyZCBjYWxsIG1vZGVsIC0gZG9pbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29u ZmVyZW5jaW5nIGluIGEgd2F5IGluY29uc2lzdGVudCB3aXRoIFJGQyA0NTc5Ljxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJU1RNIHRo YXQgaWYgNDU3OSBkb2Vzbid0IHdvcmsgZm9yIHlvdSB0aGVuIHlvdSBzaG91bGQgYmUgYmFjazxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm9wb3NpbmcgZXh0ZW5zaW9ucy9yZXZpc2lv bnMgdG8gaXQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBJZiB0aGVyZSBpcyBhIGNvbmZlcmVuY2UgYnJpZGdlIGluIHRoZSBz aWduYWxpbmcgcGF0aCwgdGhlbiBJPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3 b3VsZCBleHBlY3QgaXQgdG8gYmUgdGhlIFVBQy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbQUFdIEFsdGhvdWdoIGEg JnF1b3Q7c3RhbmRhcmQmcXVvdDsgd2F5IHRvIGludm9rZSBhIGNvbmZlcmVuY2UgaXMgdG8gc2Vu ZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYSBSRUZFUiB0byB0aGUgb3RoZXIg VUFzIHRvIGludml0ZSB0aGVtIHRvIHRoZSBjb25mZXJlbmNlIGZvY3VzLDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW4gbWFueSBkZXBsb3ltZW50cyBhIHNjZW5hcmlvIGV4aXN0 cyB3aGVyZSBhIGNhbGwgaW52b2x2ZXMgYW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IElQLVBCWCBvciBUZWxlcGhvbnkgQXBwbGljYXRpb24gU2VydmVyIChUQVMpIHRoYXQgY2Fu IGFjdCBhcyBhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmb2N1cyBmb3IgdGhl IGNvbmZlcmVuY2UuIEEgcGFydGljaXBhbnQgb2YgYSBjYWxsIGNhbiB0aGVuIGNyZWF0ZTxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYSBjb25mZXJlbmNlIGJ5IHNlbmRpbmcgYSBS RUZFUiByZXF1ZXN0IGluIGRpYWxvZyB0byB0aGUgSVAtUEJYPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBvciBUQVMgdG8gdXNlIDNQQ0MgdG8gSW52aXRlIG90aGVyIHVzZXJzIHRv IGEgY29uZmVyZW5jZS4gUmVhc29ucyBmb3IgdGhpcyBhcmUgMS48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE5vdCBhbGwgVUFzIHN1cHBvcnQgUkVGRVIsPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNvIHlvdSBhcmUg c2F5aW5nIHRoZSBpbnRlcm1lZGlhcnkgaXNuJ3QgYSBmb2N1cyAoaXRzIGEgQjJCVUEpLDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBidXQgaXQgKmNvdWxkIGJlY29tZSogYSBmb2N1cy48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgVGhlIGNvbmNlcHQgdGhhdCBhIGRpYWxvZyBtYXkgY29udGFpbiBpbnRlcm1lZGlhcmllcyB0 aGF0IGNhbiBiZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhZGRyZXNzZWQgdG8gZG8g c3R1ZmYgaXMgbm90IHBhcnQgb2YgYW55IHNpcCBzdGFuZGFyZCB0aGF0IEkgYW08YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXdhcmUgb2YuIEkgZG9uJ3QgY2FyZSB0b28gbXVjaCBhcyBs b25nIGFzIHRoZSAmcXVvdDtzdHVmZiZxdW90OyBpczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBhcHBsaWNhdGlvbiBzdHVmZiB0aGF0IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHNpcC4g QnV0IHdoZW4gaXQgaXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWx0ZXJuYXRpdmUg d2F5cyB0byBkbyBzdHVmZiB0aGF0IHNpcCBzdXBwb3J0cywgdGhlbiBJIGdldCB1cHNldC48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IDIuIE1hbnkgU0JDcyByZWplY3QgUkVGRVIgcmVxdWVzdHMgZ29pbmcgb3V0c2lkZSBkb21h aW5zIGJlY2F1c2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIHRoZSBwb3Rl bnRpYWwgZm9yIGNoYXJnaW5nIGZyYXVkIChyZWZlcnJpbmcgdG8gYSBwcmVtaXVtIHJhdGU8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG51bWJlcjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgZXRjKSAzLiBBIFVzZXIgcmVjZWl2aW5nIGEgUkVGRVIgYW5kIHRoZW4g dXNpbmcgYW4gSU5WSVRFIHRvIGpvaW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IHRoZSBjb25mZXJlbmNlIG1heSBiZSBjaGFyZ2VkIGZvciBpbml0aWF0aW5nJm5ic3A7IHRoZSBj YWxsIHdoZW4gdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzY2VuYXJpbyBp cyB0aGF0IHRoZSBpbml0aWF0b3Igb2YgdGhlIGNvbmZlcmVuY2Ugc2hvdWxkIGJlIGNoYXJnZWQu PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA0LiBObyBuZWVkIHRvIG9idGFpbiBh bmQgZGlzdHJpYnV0ZSBjb25mZXJlbmNlIFVSSXMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBQcm9ibGVtIGlzIGhvdyB0byBhY2hpZXZlIHRoZSBzYW1lIGJlaGF2aW9yIHdpdGhv dXQgZGlhbG9nIHJldXNlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGljaCBo YXMgYmVlbiBkZXByZWNhdGVkIGJ5IFJGQyA2NjY1Pzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVuIG1heWJlIHRoZSBwcm9ibGVt IG5lZWRzIHRvIGJlIGJyb3VnaHQgdXAsIGFuZCBhIHN0YW5kYXJkPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHNvbHV0aW9uIHByb3Bvc2VkLCByYXRoZXIgdGhhbiBzaW1wbHkgZW5hYmxp bmcgYSBwcm9wcmlldGFyeSBtZWNoYW5pc20uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBcyBhbm90aGVyIGV4YW1wbGUsIGNv bnNpZGVyIHNlY3Rpb24gNS4xOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERlc2Ny aXRpb246PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBUaGlzIEZlYXR1cmUtY2FwYWJpbGl0eSBpbmRpY2F0b3IgaW5kaWNhdGVzIHRoYXQgdGhl IGludGVybWVkaWFyeTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgc3VwcG9ydHMgYXVkaW8gYXMgYSBzdHJlYW1pbmcgbWVkaWEgdHlwZS48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC4uLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXhhbXBs ZXMgb2YgdHlwaWNhbCB1c2U6IEFuIElQIFBCWCBpbmRpY2F0aW5nIHRoYXQgaXQgaXM8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGNhcGFibGUgb2YgYWNjZXB0aW5nIGFuZCBpbml0aWF0aW5nIHNlc3Npb25zIHdp dGggYXVkaW8gYXMgYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RyZWFtaW5nIG1lZGlhIHR5cGUuPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgVGhpcyBkZWZpbml0aW9uICppbXBsaWVzKiBhbiBhc3N1bXB0aW9uIGFib3V0IHRoZSB3 b3JraW5nPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBlbnZpcm9ubWVudDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLSBvbmUgdGhhdCBBRkFJSyBpcyBuZXcuIEl0 IGltcGxpZXMgdGhhdCB5b3UgbmVlZCB0byBrbm93IHRoYXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGludGVybWVkaWFyaWVzIHN1cHBvcnQgYSBtZWRpYSB0eXBlIGJlZm9yZSB5 b3UgY2FuIHVzZSBpdC4gV291bGQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGl0 IGJlIGJhZCBpZiB0aGVyZSB3ZXJlIG5vIGludGVybWVkaWFyaWVzLCBhbmQgc28gbm9uZSBpbmRp Y2F0ZWQgdGhpcz88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdoYXQgaWYgc29t ZSBpbnRlcm1lZGlhcnkgKmRpZCogaW5kaWNhdGUgc3VwcG9ydCwgYnV0IHNvbWUgb3RoZXI8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvZXNuJ3QsIGJ1dCBkb2Vzbid0IGluZGlj YXRlIHRoYXQgaXQgZG9lc24ndD88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCb3R0b20gbGluZTogaG93IHdvdWxkIHRo ZSBwcmVzZW5jZSBvciBhYnNlbmNlIG9mIHRoaXMgZmVhdHVyZTxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgdGFnIGFmZmVjdCBzdWJzZXF1ZW50IHVzYWdlPzxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFtB QV0gVGhlIGFic2VuY2Ugb2YgdGhlIHN0cmVhbWluZyB0eXBlcyBkb2VzIG5vdCBpbmRpY2F0ZSB0 aGF0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgaW50ZXJtZWRpYXJ5IGRv ZXMgbm90IHN1cHBvcnQgdGhlIG1lZGlhIHR5cGUgYW5kIFNEUCBvZmZlcjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW5zd2VyIHdpbGwgdWx0aW1hdGVseSBkZXRlcm1pbmUgd2hh dCBjYW4gb3IgY2Fubm90IGJlIHVzZWQgaWY8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGFub3RoZXIgc2Vzc2lvbiBpcyBpbml0aWF0ZWQgaW52b2x2aW5nIHRoZSBpbnRlcm1lZGlh cnkuIEhvd2V2ZXI8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBwcmVzZW5j ZSBvZiB0aGUgbWVkaWEgdHlwZSBpbiBhIEZlYXR1cmUtY2FwcyBoZWFkZXIgZmllbGQ8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRvZXMgZXhwbGljdGx5IGNvbmZpcm0gdGhhdCB0 aGUgaW50ZXJtZWRpYXJ5IGRvZXMgc3VwcG9ydCB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IG1lZGlhIHR5cGUgYW5kIGluIHRoZSBzY2VuYXJpbyB3aGVyZSBhIFVBIGhhcyBh IGNob2ljZSBvZjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbXVsdGlwbGUgaW50 ZXJtZWRpYXJpZXMgaXQgY291bGQgdXNlIGZvciBhIGNvbmZlcmVuY2UgaXQgbWlnaHQ8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNob29zZSB0byB1c2UgdGhlIG9uZSB0aGF0IGV4 cGxpY2l0bHkgaW5kaWNhdGVzIGl0IHN1cHBvcnRzIHRoZSBtZWRpYSB0eXBlcyB0aGUgVUEgd2Fu dHMgdG8gdXNlLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBTbyB0aGUgVUEgd2lsbCBiZSBhYmxlIHRvIGRpc2NvdmVyIHRoYXQgKnNv bWUqIGludGVybWVkaWFyeTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdXBwb3J0cyBt ZWRpYSBpdCBpcyBpbnRlcmVzdGVkIGluLiBBbmQgaXQgY2FuIHRlbGwgdGhhdCAqc29tZSo8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW50ZXJtZWRpYXJ5IHNheXMgaXQgaXMgYSBmb2N1 cy4gSXQgZG9lc24ndCBrbm93IGlmIHRoZXkgYXJlIHRoZSBzYW1lIGludGVybWVkaWFyeS48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg QW5kIHRoZW4gdmlhIHNvbWUgb3RoZXIgZmVhdHVyZSB0YWcgaXQgb2J0YWlucyB0aGUgVVJJIG9m ICpzb21lKjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnRlcm1lZGlhcnkgb24gdGhl IHNpZ25hbGluZyBwYXRoLiBPciBtYXliZSBpdCBnZXRzIG1vcmUgdGhhbiBvbmU8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgb2YgdGhlc2UuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEl0IHRoZW4gbWFrZXMgYSBsZWFwIG9m IGZhaXRoIGFuZCBjb25mbGF0ZXMgYWxsIHRob3NlIHRoaW5ncywgdG88YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgZGV0ZXJtaW5lIHRoYXQgdGhlIFVSSSBpZGVudGlmaWVzIGEgZm9jdXMg dGhhdCBzdXBwb3J0cyB0aGlzIG1lZGlhIHR5cGUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEV2ZW4gdGhlbiwgZXhhY3RseSB3aGF0 IGRvZXMgdGhhdCBtZWFuPyBJdCBtYXkgb3IgbWF5IG5vdCBtZWFuPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IHRoYXQgaXQgc3VwcG9ydHMgbWl4aW5nIHRoYXQgbWVkaWEgdHlwZSBpbiBh IGNvbmZlcmVuY2UuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBcyBJIHN0YXRlZCBhbHJlYWR5IEkgZG9uJ3QgY2FyZSB0aGF0 IG11Y2ggYWJvdXQgdGhlc2Ugc3RyZWFtaW5nPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBtZWRpYSB0eXBlcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgY291bGQgZ28gb24sIGJ1dCB0aGlzIGlzIGVub3Vn aCBmb3Igbm93Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFtBQV0gTXkgbW90aXZhdGlvbiBmb3IgdGhpcyBpcyB0aGF0 IGN1cnJlbnRseSAzR1BQIGFyZSB1cGRhdGluZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgdGhlaXIgc3BlY2lmaWNhdGlvbnMgdG8gdXNlIFJGQyA2NjY1IGluc3RlYWQgb2YgUkZD IDMyNjUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAzR1BQIGhhcyBhIGxvdCBvZiBkaWFsb2cgcmV1c2Ugd2l0aCBTVUJTQ1JJ QkUgYW5kIFJFRkVSIHdpdGg8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVy bWVkaWFyaWVzIGFjY2VwdGluZyB0aGUgUkVGRVIgb3IgU1VCU0NSSUJFIHJlcXVlc3QgcmF0aGVy PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGFuIGZvcndhcmRpbmcgaXQgYWxs IHRoZSB3YXkgdG8gdGhlIHJlbW90ZSBVQS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQW5kIDY2NjUgZGVwcmVjYXRlcyBkaWFsIHJl dXNlIGluIG1vc3Qgb2YgdGhvc2UgY2FzZXMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFdpdGhvdXQgZGlhbG9nIHJldXNlLCB0aGUgaW50ZXJtZWRpYXJpZXMgZG9uJ3QgZ2V0IGFuIG9w cG9ydHVuaXR5PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIGludGVyY2VwdCB0aG9z ZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEluIG9yZGVyIHRvIGtub3cgdGhhdCBhbiBpbnRlcm1lZGlhcnkgc3VwcG9ydHMg dGhlIHRhcmdldCBkaWFsb2c8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1lY2hh bmlzbSZuYnNwOyBuZWVkZWQgZm9yIGEgUkVGRVIgcmVxdWVzdCBzZW50IG91dHNpZGUgdGhlIGRp YWxvZyB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd29yayB3ZSBuZWVkIHNp cC5leHRlbnNpb25zIGFzIGEgZmVhdHVyZS1jYXBhYmlsaXR5IGluZGljYXRvci4gSW48YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9yZGVyIHRvIGtub3cgdGhhdCB0aGUgbmVlZGVk IGV2ZW50IHBhY2thZ2UgaXMgc3VwcG9ydGVkIGJ5IHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgaW50ZXJtZWRpYXJ5IHNvIHdlIGNhbiBTVUJTQ1JPQkUgb3V0c2lkZSB0aGUg ZGlhbG9nIHRvIGFuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnRlcm1lZGlh cnkgd2UgbmVlZCBzaXAuZXZlbnRzIGFzIGEgZmVhdHVyZS1jYXBhYmlsaXR5IGluZGljYXRvci48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgVGhlbiBJIHRoaW5rIHlvdSBzaG91bGQgYmUgYmFjayBoZXJlIHdpdGggYSBwcm9ibGVtIHN0 YXRlbWVudCBhbmQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYSByZXF1ZXN0IGZvciBo b3cgdG8gZ2V0IHNpcCB0byBzb2x2ZSBpdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQW5kIHlvdSBzaG91bGQgdG91Y2ggYmFzZSB3 aXRoIENocmlzdGVyIG9uIHRoaXMuIEhlIG1heSBoYXZlIGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZGlmZmVyZW50IG9waW5pb24gb24gdGhlIHJlbGV2YW5jZSBvZiBmZWF0dXJlLWNh cHMgYXMgYSBzb2x1dGlvbi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQYXVs PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBPbiAxMC8yMi8xMyAzOjQ0IEFNLCBBbmRyZXcgQWxsZW4gd3JvdGU6PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQWRhbSwgUGF1bCwgUmljaGFyZCwgR29uemFs bzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCB0byBzaXBj b3JlJm5ic3A7IHRvIHJlZ2lzdGVyIGEgbnVtYmVyIG9mPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgZmVhdHVyZSBjYXBhYmlsaXR5IGluZGljYXRvcnMgaW4gdGhlIFNJUCB0 cmVlIChiYXNlZCB1cG9uIHNvbWU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBvZiB0aGUgZXhpc3RpbmcgU0lQIG1lZGlhIGZlYXR1cmUgdGFncykuIFRoZSBkcmFmdCBjYW4g YmUgZm91bmQgYXQ6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL2lkL2RyYWZ0LWFsbGVuLXNpcGNvcmUtc2lwLXRyZWUtY2FwLWluZGljYXRvcnMtMDAiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtYWxsZW4tc2lwY29y ZS1zaXAtdHJlZS1jYXAtaW5kaWNhdG9ycy0wMDwvYT4uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgdHh0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTaW5jZSB0aGVyZSB3aWxsIG5v dCBiZSBhIHNpcGNvcmUgc2Vzc2lvbiBhdCBJRVRGIzg4Jm5ic3A7IGNhbiB3ZTxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhhdmUgYW4gb2ZmbGluZSBkaXNjdXNzaW9uIG9u IGhvdyB0byBwcm9ncmVzcyB0aGlzIGRyYWZ0ICh3aGljaDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGhvcGVmdWxseSBpcyBmYWlybHkgc3RyYWlnaHRmb3J3YXJkIGFzIGl0 IGp1c3QgcmVnaXN0ZXJzIGZlYXR1cmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBjYXBhYmlsaXRpZXMgaW5kaWNhdG9ycyB3aXRoIElBTkEpLiBJIHdvdWxkbid0IHdhbnQg dG8gaGF2ZSB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdhaXQgdW50 aWwgTWFyY2ggbmV4dCB5ZWFyIGZvciBhIGRlY2lzaW9uIG9uIHByb2dyZXNzaW5nIHRoaXMuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBBbmRyZXc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAtPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg LSBUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRh aW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjb25maWRlbnRpYWwgaW5m b3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZzxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9y LWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlv bi4gQW55IHVzZSBvZjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoaXMg aW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBp czxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByb2hpYml0ZWQuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlz dHJpYnV0aW9uLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9yIHJlcHJv ZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMg bm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAtIFRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1l bnRzKSBtYXkgY29udGFpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uZmlk ZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJp YWw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByb3RlY3RlZCBieSB0aGUgc29s aWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0 aW9uLiBBbnkgdXNlIG9mPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGlzIGlu Zm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXM8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHByb2hpYml0ZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLDxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbmZvcm1hdGlv biBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiw8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRy YW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tIFRoaXMgdHJhbnNtaXNzaW9uIChp bmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5j bHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhl ciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3Jt YXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuDQogSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0 byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVt LiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRo aXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXpl ZCBhbmQgbWF5DQogYmUgdW5sYXdmdWwuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAtIFRoaXMgdHJhbnNtaXNz aW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChp bmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90 aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZv cm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFu IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4NCiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5 IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0 ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2Yg dGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3Jp emVkIGFuZCBtYXkNCiBiZSB1bmxhd2Z1bC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsgVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkg YXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmls ZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNp dG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRl IG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbg0KIGJ5 IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBp bW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlv biBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3Ig cmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uDQogYnkgdW5pbnRlbmRlZCByZWNpcGll bnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuPGJyPg0KJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQomZ3Q7Jmd0OyBUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRh Y2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2Vk IG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3It Y2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9u LXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uDQogYnkgYW55 b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVk aWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZy b20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXBy b2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24NCiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMg aXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBUaGlz IHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0 ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2Fi bGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55 IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uDQogYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVu ZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRy YW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlz c2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21p c3Npb24NCiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1h eSBiZSB1bmxhd2Z1bC48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lwY29yZSBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPC9hPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBh bnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJp dmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29s aWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0 dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbg0K IGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRl ZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFz ZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1h dGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwg b3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uDQogYnkgdW5pbnRlbmRlZCByZWNp cGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuPGJyPg0KPC9kaXY+ DQo8L2Rpdj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj5UaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFu eSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2 aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xp Y2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1 dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5 IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBp bW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlv biBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3Ig cmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50 cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLjxicj48L2JvZHk+DQo8L2h0 bWw+DQo= --_000_BBF5DDFE515C3946BC18D733B20DAD2338E3CD6EXMB104ADSrimnet_-- From pkyzivat@alum.mit.edu Fri Oct 25 13:28:16 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD2F11E8123 for ; Fri, 25 Oct 2013 13:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.625 X-Spam-Level: X-Spam-Status: No, score=0.625 tagged_above=-999 required=5 tests=[AWL=-0.738, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEj5iZvythG1 for ; Fri, 25 Oct 2013 13:28:11 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 30E4011E8108 for ; Fri, 25 Oct 2013 13:28:10 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta15.westchester.pa.mail.comcast.net with comcast id hQ641m0040Fqzac5FYUALp; Fri, 25 Oct 2013 20:28:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id hYU91m00t3ZTu2S3UYUAGN; Fri, 25 Oct 2013 20:28:10 +0000 Message-ID: <526AD459.1080908@alum.mit.edu> Date: Fri, 25 Oct 2013 16:28:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Christer Holmberg , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382732890; bh=xf7gZXD38shh3F6dU316lUeM85cZz7XlPkhtQWrI8xE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=o2INlj4erYE53KT07a8+cTainG6PjOdNzRxZLlZSgDwa689a6k/xIRt+K7uqI8jcu 4s/auqjMawNKCp7HcwFBYS/jgpRkhKwwC5XH9aT2EaoIoGSk6jxxhLlgwKnNVpW7bp ZMmpyCmDPUsPTkyXms93txV5azdZo6n0oyfAFwFImC53RpJpycj/oJAyl6vTk1GcCX 6+AJE9g9I+B4lQGznFZ+z+zwK2snnRi8mrFhgilVGTmA1A9ZI6N4t3Z/UzJU3g1452 RGQXzpYt+0AFBzV39MuRQE+iPANvTVrWAlJYgCFdNG/3Pij7UZ01u/B+LzsXhRZEqu DfjQ2rNSqEHmw== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:28:16 -0000 Inline. On 10/25/13 2:57 PM, Christer Holmberg wrote: > Hi, > > .... > >>> /Example:/ >>> >>> I support the find-Paul feature, and I insert a FCI: >>> >>> Feature-Caps: *, +g.find-paul="sip:pkyzivat@alum.mit.edu" >>> >>> Now, in this case the address does NOT point to my entity, but to Paul's >>> entity. My entity supports a feature, which provides Paul's address. >>> >>> So, if the FCI says: >>> >>> Feature-Caps: *, >>> +g.find-paul="sip:pkyzivat@alum.mit.edu";+sip.methods="invite" >>> >>> ...it doesn't automatically mean that I can contact Paul using INVITE. >>> By default it means that MY entity supports the INVITE method - which >>> from the find-paul feature perspective is useless information. >>> >>> So, in the FCI specification for +g.find-paul, I would have to >>> explictily describe how the FCI works in conjunction with other FCIs. I >>> would have to explicitly say that, when used together +sip.methods, the >>> +sip.methods indicates which SIP methods I can use to contact Paul >>> (using the address provide in the +g.find-paul FCI). >> >> So far I agree. >> >> But suppose there is also a find-christer FCI. So we have: >> >> Feature-Caps: * >> ;+g.find-paul="sip:pkyzivat@alum.mit.edu" >> ;+g.find-paul="sip:christer.holmberg@ericsson.com" >> ;+sip.methods="invite" >> >> And both find-paul and find-christer want to define the use of other >> FCIs. Then things start to become ambiguous. >> >> Should the description of find-paul specify what other FCIs "pertain" to >> it? Or should the description of sip.methods specify what FCI(s) provide >> the address at which it applies? Or both? What if paul and christer >> support different methods? > > In that case you would need to have two different Feature-Caps header > fields: > > Feature-Caps: > *;+g.find-paul="sip:pkyzivat@alum.mit.edu";+sip.methods="invite" > Feature-Caps: > *;+g.find-paul="sip:christer.holmberg@ericsson.com";+sip.methods="message" That seemingly solves the problem, but if the same entity inserts them both then its a questionable use of Feature-caps isn't it? > In your example you had two instances of the same FCI (is that even > allowed?), I did? find-paul and find-christer are two different FCIs. (But that sort of naming will be troublesome for the registry and for the expert who has to approve entries in it.:-) but there could also have been a case with two different > FCIs, both using +sip.methods, in which case you may have to put them > into separate Feature-Caps header fields. > > These things would have to be clearly specified. Very definitely. Thanks, Paul > Regards, > > Christer > > >> Section 5.3.8 in RFC 6809 also says: >> >> "If there is additional information about the feature-capability >> indicator, it is recommended to describe such information. It can >> include, for example, *names of related feature-capability >> indicators*." >> >> So, in your case, I think the +g.3gpp.see_trans FCI specifiction would >> have to specify how the FCI is used in conjuntion with other FCIs, >> including the +sip.method FCI. >> >> Something like: "When the session transfer request is sent to the >> address indicated by the FCI value, the +sip.method FCI indicates which >> SIP methods can be used." >> >> Regards, >> >> Christer >> >> >> >> *From*: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> *Sent*: Friday, October 25, 2013 12:01 PM Central Standard Time >> *To*: Andrew Allen; Paul Kyzivat ; Gonzalo >> Camarillo >> *Cc*: rlb@ipv.sx ; adam@nostrum.com ; >> mary.ietf.barnes@gmail.com >> *Subject*: RE: New sipcore draft submission >> draft-allen-sipcore-sip-tree-cap-indicators >> >> Hi, >> >>>I think we can have an FCI >> >>> >> >>>Feature-Caps: *;+g.3ggp.sess_trans=”sip:foo@example.com;gr” >> >>> >> >>>Indicating that the entity supports 3GPP session transfer and the address where you send the session transfer request is sip:foo@example.com;gr >> >> Correct. The FCI itself indicates support of session transfer feature, >> and the FCI value indicates the address associatd with the feature. >> >>>Also if I have: >> >>> >> >>>Feature-Caps: *;+g.3ggp.sess_trans=sip:foo@example.com;gr; +sip.extensions=”replaces, tdialog”; >> +sip.methods=”invite, refer, bye, options, update, prack” >> >>> >> >>> This means the entity supports 3GPP session transfer and the address where you send the session transfer request is sip:foo@example.com;gr ... >> >> Correct. >> >>> ...supports the replaces and target dialog extensions and supports the following methods - invite, refer, bye, options, update, prack. >> >> Technically, what it means is that there is *AN* entity which supports >> the features listed above, and the address is where you are to send the >> session transfer request in order to trigger the 3GPP session transfer >> feature. >> >> Regards, >> >> Christer >> >> *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> *Sent:* Friday, October 25, 2013 10:25 AM >> *To:* Paul Kyzivat; Andrew Allen; Gonzalo Camarillo >> *Cc:* rlb@ipv.sx; adam@nostrum.com; mary.ietf.barnes@gmail.com >> *Subject:* RE: New sipcore draft submission >> draft-allen-sipcore-sip-tree-cap-indicators >> >> Hi, >> >> As Paul said, if one needs to provide address information associated >> with a FCI, the address information cannot be a FCI of its own. It needs >> to be a value of the FCI for which it is associated. >> >> Something like: >> >> Feature-Caps: *;+audio="sip:foo@example.com" >> >> (Also note that the "+" sign is mandatory for all FCIs - no matter which >> registry tree they belong to) >> >> Regards, >> >> Christer >> >> ------------------------------------------------------------------------ >> >> *From:*Paul Kyzivat [pkyzivat@alum.mit.edu] >> *Sent:* Friday, 25 October 2013 5:06 PM >> *To:* Andrew Allen; Gonzalo Camarillo >> *Cc:* rlb@ipv.sx ; adam@nostrum.com >> ; Christer Holmberg; mary.ietf.barnes@gmail.com >> >> *Subject:* Re: New sipcore draft submission >> draft-allen-sipcore-sip-tree-cap-indicators >> >> Andrew, >> >> (I see this is still on the private thread. I'll reply here, but this >> exchange should probably be reposted to the sipcore list as part of the >> public discussion of the draft.) >> >> On 10/24/13 10:41 PM, Andrew Allen wrote: >>> >>> Paul >>> >>> I am happy to do a revision with more details on the semantics of the capability indicators. However I don't think it should be held to a very much higher bar than the details in RFC 3840 and the other media feature tag RFCs regarding the meaning of thosetags. >> >> Keep in mind that the driving force for the definition of feature tags >> in 3840 was in support of callerprefs (3841). So the context for the use >> of feature tags was that they would be placed on Contacts in REGISTER >> requests. So you can interpret the definitions in that context: that a >> request sent to an AOR using callerprefs can affect the choice of which >> device the request goes to according to the capabilities it wants. In >> that context audio, video, isfocus all make sense. >> >> Their use on Contacts in dialogs was derivative to that: because >> callerpref support is optional, there is no guarantee that the device >> you reach via callerprefs will have the capabilities you requested. So >> the values in the contact help confirm what you got. >> >> Of course they have since been used other ways. And the descriptions of >> them don't necessarily reflect that. IMO that is a defect due to the >> evolution of use. >> >> I'm looking for the same sort of context for use with the feature-caps. >> >> In private discussion you indicated to me that you expected the feature >> caps to be grouped - with one of them giving the URI of the device that >> the other tags apply to. I guess this would end up looking something like: >> >> Feature-Caps: *;g.uri="sip:foo@example.com";audio >> Feature-Caps: *;g.uri="sip:bar@example.com";audio;video;isfocus >> Feature-Caps: *;g.uri="sip:baz@example.com";text >> >> (I'm making up g.uri for the example.) >> >> And then presumably somebody on the signaling path will "shop" in the >> feature caps for the capabilities it wants, and then send a request to >> that URI, with the expectation that the UA responding will have those >> capabilities. >> >>> The semantics should be no different than those of the corresponding existing media feature tag if it is present in the Contact header. >> >> Note that 6809 says: >> >> When a SIP entity receives a SIP request, or response, that contains >> one or more Feature-Caps header fields, the feature-capability >> indicators in the header field inform the entity about the features >> and capabilities supported by entities in the SIP message signaling >> path. The procedure by which features and capabilities are invoked >> are outside the scope of this specification and MUST be described by >> individual feature-capability indicator specifications. >> >> A Feature-Caps header field value cannot convey the address of the >> SIP entity that inserted the Feature-Caps header field. If >> additional data about a supported feature needs to be conveyed, such >> as the address of the SIP entity that indicated support of the >> feature, then the feature definition needs to define a way to convey >> that information as a value of the associated feature-capability >> indicator. >> >> This was discussed at length while that RFC was under consideration. Yet >> the definitions of the tags in *this* draft don't specify that. >> >>> The registration templates currently reference the RFC 3840 and the other RFCs that define the other media feature tags that correspond to these feature capability indicators. >> >> And those definitions were written to be understood in the context of >> 3840/3841. They make sense in that context, but not in *this* context. >> >> Thanks, >> Paul >> >>> But if more explicit detail is required then I can add some more text or alternatively remove the less important ones if they are going to become rat holes. The ones I regard as really important and urgent are sip.methods, sip.extensions and sip.events the meaning of which I think should be quite clear. >>> >>> Andrew >>> >>> ----- Original Message ----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >>> To: Andrew Allen;Gonzalo.Camarillo@ericsson.com >> > >>> Cc:rlb@ipv.sx >; >> adam@nostrum.com > >; christer.holmberg@ericsson.com >> > >; mary.ietf.barnes@gmail.com >> > >; Paul Kyzivat >> > >>> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators >>> >>> On 10/24/13 4:07 PM, Andrew Allen wrote: >>>> >>>> Paul >>>> >>>> Ok >>>> >>>> So we are basically where I thought we were at when I submitted the draft. >>>> >>>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who indicates interest) can have some offline discussion in Vancouver on whether and how to progress this. >>> >>> As I indicated again on the sipcore list, I found the that the draft >>> didn't explain nearly enough to allow meaningful use of these. >>> I know you replied, and I will continue the conversation there. >>> But I will be opposed to these until and unless the draft (and notably >>> the descriptions of the tags) are clear about how one could figure out >>> what can do in the presence of the tags that one couldn't do without >>> them. AND, that the behavior that suggests doesn't "break" sip. (E.g., >>> by advocating a new and incompatible way to do something.) >>> >>> We can continue this on the sipcore list. >>> >>> Thanks, >>> Paul >>> >>>> Andrew >>>> >>>> ----- Original Message ----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >>>> To: Andrew Allen; Gonzalo Camarillo > >>>> Cc: Richard Barnes (rlb@ipv.sx ) >; Adam >> Roach (adam@nostrum.com ) > >; Christer Holmberg >> (christer.holmberg@ericsson.com ) >> > >; Mary Barnes >> (mary.ietf.barnes@gmail.com ) < >> mary.ietf.barnes@gmail.com > >>>> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> On 10/24/13 2:17 PM, Andrew Allen wrote: >>>>> Paul >>>>> >>>>> That is fine. Although Mary in her reply to me seemed to indicate maybe there was a possibility to use some of the DISPATCH spare time for a SIPCORE session for this. Is that a possibility? >>>>> >>>>> I already replied to your post >>>> >>>> I discussed that with Adam. We decided we can't set a precedent to spin >>>> up a session to discuss a draft that hasn't had substantial (any) list >>>> discussion. >>>> >>>> But list discussion is always welcome. >>>> >>>> Sorry, >>>> Paul >>>> >>>>> Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Sent: Thursday, October 24, 2013 1:31 PM >>>>> To: Andrew Allen; Gonzalo Camarillo >>>>> Cc: Richard Barnes (rlb@ipv.sx ); Adam Roach (adam@nostrum.com >> ); Christer Holmberg >> (christer.holmberg@ericsson.com ) >>>>> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators >>>>> >>>>> Andrew, >>>>> >>>>> I spoke with Mary about it, and we concluded that dispatch isn't right for this. (In addition to being clearly sipcore, it didn't meet the deadline for dispatch.) I was wrong to encourage you that way. >>>>> >>>>> So no official live discussion in Vancouver. (But informal discussion >>>>> fine.) >>>>> >>>>> I'll resend my private comments to the sipcore list to kickstart some discussion there. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>>>> I just emailed Mary asking for agenda time. Should I cancel that request? >>>>>> >>>>>> -----Original Message----- >>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>>> Sent: Thursday, October 24, 2013 1:00 PM >>>>>> To: Paul Kyzivat >>>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx ); Adam Roach >>>>>> (adam@nostrum.com ); Christer Holmberg >> (christer.holmberg@ericsson.com ) >>>>>> Subject: Re: New sipcore draft submission >>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>> >>>>>> Hi Paul, >>>>>> >>>>>> given that you think this belongs to SIPCORE, I do not see the need to run it through DISPATCH. Please, start technical discussions on the draft on the SIPCORE list. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>>>> Paul >>>>>>>> >>>>>>>> Thanks for reviewing the draft already and giving me early feedback. >>>>>>>> >>>>>>>> My responses below inline (prepended with [AA). >>>>>>>> >>>>>>>> Can I ask the ADs to determine ASAP if this needs to go to DISPATCH >>>>>>>> first or not. As outlined below my view is that it is unnecessary >>>>>>>> for every little thing to go to DISPATCH as this just creates >>>>>>>> additional delay and overhead. If it is to be discussed in DISPATCH >>>>>>>> then I definitely would want agenda time atIETF#88 for this. >>>>>>> >>>>>>> Having now seen Andrew's responses to my initial questions, I think >>>>>>> this >>>>>>> *needs* to be carefully considered by sipcore. IMO this has the >>>>>>> potential to create a dialect of sip that is incompatible with normal >>>>>>> usage. (Maybe IMS has already done that. But this will make it >>>>>>> worse.) >>>>>>> >>>>>>> But if there is a desire to discuss it publicly in Vancouver then >>>>>>> dispatch is the opportunity and so some discussion on the dispatch >>>>>>> list in advance of that would be appropriate. >>>>>>> >>>>>>> I'll defer to the ADs on this. >>>>>>> >>>>>>> More inline. >>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx ); Gonzalo Camarillo >>>>>>>> (Gonzalo.Camarillo@ericsson.com ); >> Adam Roach (adam@nostrum.com ) >>>>>>>> Subject: Re: New sipcore draft submission >>>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>>> >>>>>>>> Andrew, >>>>>>>> >>>>>>>> On a legalistic note, its questionable to me whether this kind of >>>>>>>> action falls within the scope of sipcore. OTOH, among existing wgs, >>>>>>>> sipcore is probably the best suited to discuss the proposal. We >>>>>>>> could take it to DISPATCH. I think DISPATCH has extra time in its >>>>>>>> agenda for Vancouver, so that might be one option for you. But then >>>>>>>> I don't know where dispatch would dispatch it. It may be that AD >>>>>>>> sponsored is the best way to go. >>>>>>>> >>>>>>>> [AA] It seemed to me that sipcore was the right place. This draft >>>>>>>> registers feature-capability indicators in a registry that was >>>>>>>> created by a sipcore RFC (RFC 6809). You could in my view make an >>>>>>>> argument that this should even have been done as part of RFC 6809. >>>>>>> >>>>>>> If this was just a matter of registering some new feature caps that >>>>>>> were not controversial, then I don't think sipcore needs to be involved. >>>>>>> >>>>>>> But as I mentioned above, I do consider these controversial. >>>>>>> >>>>>>>> Discussing it now on the dispatch list would be a good start toward >>>>>>>> discussing it at the dispatch session. >>>>>>>> >>>>>>>> [AA] Can I ask the ADs to determine if this needs to go to DISPATCH >>>>>>>> first or not. My view is that it is unnecessary for every little >>>>>>>> thing to go to DISPATCH as this just creates additional delay and overhead. >>>>>>>> This just registers some indicators in an existing IANA registry and >>>>>>>> is not (or should not be IMHO) a major project. >>>>>>> >>>>>>> To me this is a matter of whether you want to be opportunistic. >>>>>>> If this went to dispatch I would now recommend that it be dispatched >>>>>>> to sipcore. So its a matter of whether you want to talk about it in >>>>>>> the dispatch meeting. >>>>>>> >>>>>>>> Regarding substance, this draft troubles me. It takes feature-caps >>>>>>>> in exactly the direction that I found most concerning about the >>>>>>>> mechanism in the first place. >>>>>>>> >>>>>>>> Your draft partitions the existing media feature tags into two sets >>>>>>>> - those that would be useful as feature-capability-indicators, and >>>>>>>> those that aren't. But I see no explanation of the criteria used to >>>>>>>> make this distinction, nor can I think of one. >>>>>>>> >>>>>>>> [AA] I based this decision on the following criteria: If a feature >>>>>>>> tag was potentially at all useful for an intermediary to indicate it >>>>>>>> then include it in the registry. The ones not included are either >>>>>>>> directly associated with the user (intermediaries are not directly >>>>>>>> associated with the user) or would only ever have one value (e.g >>>>>>>> automata). I am not sure that every feature-capability indicator >>>>>>>> proposed to be registered is actually useful but then I don't think >>>>>>>> every media feature tag registered by RFC 3840 is either (I doubt >>>>>>>> very much if there are implementation using the sip.application or >>>>>>>> sip.control feature tags). I don't think RFC 3840 goes into a lot of >>>>>>>> details justifying of ever registered media feature tag and >>>>>>>> specifying the details of how they would be used either. I am >>>>>>>> willing to remove any feature-capability indicators that are >>>>>>>> controversial except that I think we definitely need sip.extensions, sip.methods and sip.events. >>>>>>>> There is a significant overhead to writing an >>>>>>> d progressing internet drafts so my view is lets register all that >>>>>>> might be remotely useful in the same document. >>>>>>> >>>>>>> The judgement of "useful" is reasonable. But I still can't discern >>>>>>> what the use is from the iana registration descriptions. >>>>>>> >>>>>>>> For the ones that you have requested feature capability indicators, >>>>>>>> I cannot figure out what using them would mean. For example, when I >>>>>>>> see isFocus on a Contact header I know I am in a conference, and >>>>>>>> that I can subscribe to the conference event package at the contact >>>>>>>> URI. If I see isFocus in a Feature-Caps header, what does it mean? >>>>>>>> What can I do once I know this? >>>>>>>> >>>>>>>> Section 5.14 of this draft says: >>>>>>>> >>>>>>>> This Feature-capability indicator indicates that the intermediary >>>>>>>> is a conference server, also known as a focus, and is capable of >>>>>>>> mixing together the media for all calls to the same URI. >>>>>>>> ... >>>>>>>> Examples of typical use: A conference bridge indicating >>>>>>>> that it >>>>>>>> is a conference bridge and is capable of acting as a >>>>>>>> conference >>>>>>>> focus for this session. >>>>>>>> >>>>>>>> [AA] the presence of isfocus in a Feature-Caps header field means >>>>>>>> that a UA can initiate a conference by sending a REFER request to >>>>>>>> the intermediary to invite another user and create a multi user >>>>>>>> conference from the 1-1 session. >>>>>>>> >>>>>>>> Note that Feature-Caps doesn't indicate which entity has this >>>>>>>> capability, only that something does. And since this would >>>>>>>> presumably only be used if it wasn't the UAC of the request, sending >>>>>>>> a subscribe to the contact address of the UAC wouldn't make sense. >>>>>>>> >>>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I consider >>>>>>>> this application specific and so this would be included in a feature >>>>>>>> tag registered in the global tree as stated in the draft "RFC 6809 >>>>>>>> [1] provides that addresses of intermediaries can be communicated as >>>>>>>> a value of an associated feature-capability indicator so it would be >>>>>>>> appropriate to define feature capability indicators as part of the >>>>>>>> global tree to communicate the GRUU of the intermediary and hence >>>>>>>> this is outside the scope of this document." - RFC 6809 states " If >>>>>>>> additional data about a supported feature needs to be conveyed, such >>>>>>>> as the address of the SIP entity that indicated support of the >>>>>>>> feature, then the feature definition needs to define a way to convey >>>>>>>> that information as a value of the associated feature-capability >>>>>>>> indicator." However I think the SIP specific capability indicators >>>>>>>> such as methods, extensions and events should appropriately be >>>>>>>> registered in the SIP tree not as proprietary indicator >>>>>>> s in the global tree. >>>>>>> >>>>>>> So you have defined a sip tree feature tag that is only useful in >>>>>>> conjunction with another feature tag from the global tree. >>>>>>> And the description of this feature tag doesn't even mention that. >>>>>>> >>>>>>> And this all implies a completely non-standard call model - doing >>>>>>> conferencing in a way inconsistent with RFC 4579. >>>>>>> >>>>>>> ISTM that if 4579 doesn't work for you then you should be back >>>>>>> proposing extensions/revisions to it. >>>>>>> >>>>>>>> If there is a conference bridge in the signaling path, then I would >>>>>>>> expect it to be the UAC. >>>>>>>> >>>>>>>> [AA] Although a "standard" way to invoke a conference is to send a >>>>>>>> REFER to the other UAs to invite them to the conference focus, in >>>>>>>> many deployments a scenario exists where a call involves an IP-PBX >>>>>>>> or Telephony Application Server (TAS) that can act as a focus for >>>>>>>> the conference. A participant of a call can then create a conference >>>>>>>> by sending a REFER request in dialog to the IP-PBX or TAS to use >>>>>>>> 3PCC to Invite other users to a conference. Reasons for this are 1. >>>>>>>> Not all UAs support REFER, >>>>>>> >>>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), but >>>>>>> it *could become* a focus. >>>>>>> >>>>>>> The concept that a dialog may contain intermediaries that can be >>>>>>> addressed to do stuff is not part of any sip standard that I am aware >>>>>>> of. I don't care too much as long as the "stuff" is application stuff >>>>>>> that is outside the scope of sip. But when it is alternative ways to >>>>>>> do stuff that sip supports, then I get upset. >>>>>>> >>>>>>>> 2. Many SBCs reject REFER requests going outside domains because of >>>>>>>> the potential for charging fraud (referring to a premium rate number >>>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to join >>>>>>>> the conference may be charged for initiating the call when the >>>>>>>> scenario is that the initiator of the conference should be charged. >>>>>>>> 4. No need to obtain and distribute conference URIs. >>>>>>>> Problem is how to achieve the same behavior without dialog reuse >>>>>>>> which has been deprecated by RFC 6665? >>>>>>> >>>>>>> Then maybe the problem needs to be brought up, and a standard >>>>>>> solution proposed, rather than simply enabling a proprietary mechanism. >>>>>>> >>>>>>>> As another example, consider section 5.1: >>>>>>>> >>>>>>>> Descrition: >>>>>>>> This Feature-capability indicator indicates that the intermediary >>>>>>>> supports audio as a streaming media type. >>>>>>>> ... >>>>>>>> Examples of typical use: An IP PBX indicating that it is >>>>>>>> capable of accepting and initiating sessions with audio as a >>>>>>>> streaming media type. >>>>>>>> >>>>>>>> This definition *implies* an assumption about the working >>>>>>>> environment >>>>>>>> - one that AFAIK is new. It implies that you need to know that >>>>>>>> intermediaries support a media type before you can use it. Would it >>>>>>>> be bad if there were no intermediaries, and so none indicated this? >>>>>>>> What if some intermediary *did* indicate support, but some other >>>>>>>> doesn't, but doesn't indicate that it doesn't? >>>>>>>> >>>>>>>> Bottom line: how would the presence or absence of this feature tag >>>>>>>> affect subsequent usage? >>>>>>>> >>>>>>>> [AA] The absence of the streaming types does not indicate that the >>>>>>>> intermediary does not support the media type and SDP offer answer >>>>>>>> will ultimately determine what can or cannot be used if another >>>>>>>> session is initiated involving the intermediary. However the >>>>>>>> presence of the media type in a Feature-caps header field does >>>>>>>> explictly confirm that the intermediary does support the media type >>>>>>>> and in the scenario where a UA has a choice of multiple >>>>>>>> intermediaries it could use for a conference it might choose to use >>>>>>>> the one that explicitly indicates it supports the media types the UA wants to use. >>>>>>> >>>>>>> So the UA will be able to discover that *some* intermediary supports >>>>>>> media it is interested in. And it can tell that *some* intermediary >>>>>>> says it is a focus. It doesn't know if they are the same intermediary. >>>>>>> >>>>>>> And then via some other feature tag it obtains the URI of *some* >>>>>>> intermediary on the signaling path. Or maybe it gets more than one of >>>>>>> these. >>>>>>> >>>>>>> It then makes a leap of faith and conflates all those things, to >>>>>>> determine that the URI identifies a focus that supports this media type. >>>>>>> >>>>>>> Even then, exactly what does that mean? It may or may not mean that >>>>>>> it supports mixing that media type in a conference. >>>>>>> >>>>>>>> As I stated already I don't care that much about these streaming >>>>>>>> media types. >>>>>>> >>>>>>>> I could go on, but this is enough for now. >>>>>>>> >>>>>>>> [AA] My motivation for this is that currently 3GPP are updating >>>>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>>>> >>>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with >>>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather than >>>>>>>> forwarding it all the way to the remote UA. >>>>>>> >>>>>>> And 6665 deprecates dial reuse in most of those cases. >>>>>>> Without dialog reuse, the intermediaries don't get an opportunity to >>>>>>> intercept those. >>>>>>> >>>>>>>> In order to know that an intermediary supports the target dialog >>>>>>>> mechanism needed for a REFER request sent outside the dialog to >>>>>>>> work we need sip.extensions as a feature-capability indicator. In >>>>>>>> order to know that the needed event package is supported by the >>>>>>>> intermediary so we can SUBSCROBE outside the dialog to an >>>>>>>> intermediary we need sip.events as a feature-capability indicator. >>>>>>> >>>>>>> Then I think you should be back here with a problem statement and a >>>>>>> request for how to get sip to solve it. >>>>>>> >>>>>>> And you should touch base with Christer on this. He may have a >>>>>>> different opinion on the relevance of feature-caps as a solution. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>>>> >>>>>>>>> I have submitted a new draft to sipcore to register a number of >>>>>>>>> feature capability indicators in the SIP tree (based upon some of >>>>>>>>> the existing SIP media feature tags). The draft can be found at: >>>>>>>>> >>>>>>>>>http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00. >>>>>>>>> txt >>>>>>>>> >>>>>>>>> Since there will not be a sipcore session at IETF#88 can we have >>>>>>>>> an offline discussion on how to progress this draft (which >>>>>>>>> hopefully is fairly straightforward as it just registers feature >>>>>>>>> capabilities indicators with IANA). I wouldn't want to have to wait >>>>>>>>> until March next year for a decision on progressing this. >>>>>>>>> >>>>>>>>> Andrew >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------- >>>>>>>>> - >>>>>>>>> - This transmission (including any attachments) may contain >>>>>>>>> confidential information, privileged material (including material >>>>>>>>> protected by the solicitor-client or other applicable privileges), >>>>>>>>> or constitute non-public information. Any use of this information >>>>>>>>> by anyone other than the intended recipient is prohibited. If you >>>>>>>>> have received this transmission in error, please immediately reply >>>>>>>>> to the sender and delete this information from your system. Use, >>>>>>>>> dissemination, distribution, or reproduction of this transmission >>>>>>>>> by unintended recipients is not authorized and may be unlawful. >>>>>>>> >>>>>>>> -------------------------------------------------------------------- >>>>>>>> - This transmission (including any attachments) may contain >>>>>>>> confidential information, privileged material (including material >>>>>>>> protected by the solicitor-client or other applicable privileges), >>>>>>>> or constitute non-public information. Any use of this information by >>>>>>>> anyone other than the intended recipient is prohibited. If you have >>>>>>>> received this transmission in error, please immediately reply to the >>>>>>>> sender and delete this information from your system. Use, >>>>>>>> dissemination, distribution, or reproduction of this transmission by >>>>>>>> unintended recipients is not authorized and may be unlawful. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this informationby anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the >> sender and delete this information from your system. Use, dissemination, >> distribution, or reproduction of this transmission by unintended >> recipients is not authorized and may be unlawful. >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this informationby anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the >> sender and delete this information from your system. Use, dissemination, >> distribution, or reproduction of this transmission by unintended >> recipients is not authorized and may be unlawful. >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this informationby anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the >> sender and delete this information from your system. Use, dissemination, >> distribution, or reproduction of this transmission by unintended >> recipients is not authorized and may be unlawful. >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this informationby anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the >> sender and delete this information from your system. Use, dissemination, >> distribution, or reproduction of this transmission by unintended >> recipients is not authorized and may be unlawful. >>> >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute >> non-public information. Any use of this information by anyone other than >> the intended recipient is prohibited. If you have received this >> transmission in error, please immediately reply to the sender and delete >> this information from your system. Use, dissemination, distribution, or >> reproduction of this transmission by unintended recipients is not >> authorized and may be unlawful. >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential >> information, privileged material (including material protected by the >> solicitor-client or other applicable privileges), or constitute >> non-public information. Any use of this information by anyone other than >> the intended recipient is prohibited. If you have received this >> transmission in error, please immediately reply to the sender and delete >> this information from your system. Use, dissemination, distribution, or >> reproduction of this transmission by unintended recipients is not >> authorized and may be unlawful. >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@alum.mit.edu Fri Oct 25 13:31:43 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE5411E8191 for ; Fri, 25 Oct 2013 13:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.634 X-Spam-Level: X-Spam-Status: No, score=0.634 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrzHp-otoYJA for ; Fri, 25 Oct 2013 13:31:38 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id EC95B11E8108 for ; Fri, 25 Oct 2013 13:31:37 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta14.westchester.pa.mail.comcast.net with comcast id hYBd1m0011wpRvQ5EYXdQh; Fri, 25 Oct 2013 20:31:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id hYXc1m00X3ZTu2S3eYXcZ1; Fri, 25 Oct 2013 20:31:37 +0000 Message-ID: <526AD528.8020108@alum.mit.edu> Date: Fri, 25 Oct 2013 16:31:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Christer Holmberg , Andrew Allen , SIPCORE References: <526A7ADF.8010106@alum.mit.edu> , <526ABAAC.1000304@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C4F70BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4F70E4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4F70E4@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382733097; bh=ToEaxaKaH08U3R526QfT06FaEss5ZTBxVtLWfqXeVmI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pjcU9drhTWB5rHcrYGxUzGqzow/Yw8a/ObTfQLE8OKPHWi67kr9ifYlyfQ56lAc0d kuyWC1uglJWBrHBzyMnLWmKDLHTiQMsNn3+Io8cuiz1wEEhSSH6doooW77ClGAS6S/ vHCFuZ8gG2AVWRY89JIr2nOZyo2j/+pRVjkx6w90CEkuDhZT0AhRrRs+DasV4rpqaA oKzIiBs3jhFBBdIYEbyfk1gQl1SVWUtcPjg9VzTu9mnHESvYa+y4ybpq6NJDXUbVaR enVQYTD4/FMEH3EI/S5jy/rT+rQci9pEzgBhnZj1Wy3yWfR48XWPl4LBlCU59fcTgj y5AMAn9b5MMIw== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:31:43 -0000 On 10/25/13 2:49 PM, Christer Holmberg wrote: > As a side note, you can also indicate a SIP method as a URI parameter: > > sip:transfer@example.com;method=refer Yes. But *that* has its own semantics. It means that when you use that URI in a request, the method should be REFER. I don't think it is very relevant to this discussion. (I have always had a problem with that one. If I'm planning to send an INVITE, but the URI I choose says I should use REFER, my logic probably won't work with REFER in place of INVITE.) Thanks, Paul > ------------------------------------------------------------------------ > *From:* sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] on behalf of > Christer Holmberg [christer.holmberg@ericsson.com] > *Sent:* Friday, 25 October 2013 9:47 PM > *To:* Paul Kyzivat; Andrew Allen; SIPCORE > *Subject:* Re: [sipcore] New sipcore draft submission > draft-allen-sipcore-sip-tree-cap-indicators > > Hi, > >>> The next revisions will contain more details on what each FCI (as Christer now calls them means). >>> >>> If some are not well understood I will remove them from the draft (i.e. drop the rat holes) >>> >>> I think my email exchange with Christer clarifies the other points. >>> >>> Does this represent in principle a way forward? >> >> Maybe. We'll have to see how it goes. >> >> The challenge is, I think, that you want to bring in a bunch of the 3840 >> feature tags, and have them mean something akin to what they do as >> feature tags when used as FCIs. But there needs to be some way to >> describe what *each* one means. It's not immediately clear to me how to >> do that. > > As I said in another reply, I think that the FCIs that use the > +sip.method etc FCIs need to describe how they are used in conjunction. > > Example: > > Feature-Caps: *;+g.x;+sip.methods="INVITE" > > Feature-Caps: *;+g.y;+sip.methods="INVITE" > > The FCI specifications for +g.x and +g.y need to describe how they are > used together with +sip.methods, if there is a relationship. > > Otherwise +sip.methods only means that the entity that inserted the FCIs > support "INVITE". > > Regards, > > Christer > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Friday, October 25, 2013 10:06 AM >> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com >> Cc: rlb@ipv.sx; adam@nostrum.com; christer.holmberg@ericsson.com; mary.ietf.barnes@gmail.com >> Subject: Re: New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators >> >> Andrew, >> >> (I see this is still on the private thread. I'll reply here, but this exchange should probably be reposted to the sipcore list as part of the public discussion of the draft.) >> >> On 10/24/13 10:41 PM, Andrew Allen wrote: >>> >>> Paul >>> >>> I am happy to do a revision with more details on the semantics of the capability indicators. However I don't think it should be held to a very much higher bar than the details in RFC 3840 and the other media feature tag RFCs regarding the meaning of those tags. >> >> Keep in mind that the driving force for the definition of feature tags in 3840 was in support of callerprefs (3841). So the context for the use of feature tags was that they would be placed on Contacts in REGISTER requests. So you can interpret the definitions in that context: that a request sent to an AOR using callerprefs can > affect the choice of which device the request goes to according to the > capabilities it wants. In that context audio, video, isfocus all make sense. >> >> Their use on Contacts in dialogs was derivative to that: because callerpref support is optional, there is no guarantee that the device you reach via callerprefs will have the capabilities you requested. So the values in the contact help confirm what you got. >> >> Of course they have since been used other ways. And the descriptions of them don't necessarily reflect that. IMO that is a defect due to the evolution of use. >> >> I'm looking for the same sort of context for use with the feature-caps. >> >> In private discussion you indicated to me that you expected the feature caps to be grouped - with one of them giving the URI of the device that the other tags apply to. I guess this would end up looking something like: >> >> Feature-Caps: *;g.uri="sip:foo@example.com";audio >> Feature-Caps: *;g.uri="sip:bar@example.com";audio;video;isfocus >> Feature-Caps: *;g.uri="sip:baz@example.com";text >> >> (I'm making up g.uri for the example.) >> >> And then presumably somebody on the signaling path will "shop" in the feature caps for the capabilities it wants, and then send a request to that URI, with the expectation that the UA responding will have those capabilities. >> >>> The semantics should be no different than those of the corresponding existing media feature tag if it is present in the Contact header. >> >> Note that 6809 says: >> >> When a SIP entity receives a SIP request, or response, that contains >> one or more Feature-Caps header fields, the feature-capability >> indicators in the header field inform the entity about the features >> and capabilities supported by entities in the SIP message signaling >> path. The procedure by which features and capabilities are invoked >> are outside the scope of this specification and MUST be described by >> individual feature-capability indicator specifications. >> >> A Feature-Caps header field value cannot convey the address of the >> SIP entity that inserted the Feature-Caps header field. If >> additional data about a supported feature needs to be conveyed, such >> as the address of the SIP entity that indicated support of the >> feature, then the feature definition needs to define a way to convey >> that information as a value of the associated feature-capability >> indicator. >> >> This was discussed at length while that RFC was under consideration. Yet the definitions of the tags in *this* draft don't specify that. >> >>> The registration templates currently reference the RFC 3840 and the other RFCs that define the other media feature tags that correspond to these feature capability indicators. >> >> And those definitions were written to be understood in the context of 3840/3841. They make sense in that context, but not in *this* context. >> >> Thanks, >> Paul >> >>> But if more explicit detail is required then I can add some more text or alternatively remove the less important ones if they are going to become rat holes. The ones I regard as really important and urgent are sip.methods, sip.extensions and sip.events the meaning of which I think should be quite clear. >>> >>> Andrew >>> >>> ----- Original Message ----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >>> To: Andrew Allen; Gonzalo.Camarillo@ericsson.com >>> >>> Cc: rlb@ipv.sx ; adam@nostrum.com ; >>> christer.holmberg@ericsson.com ; >>> mary.ietf.barnes@gmail.com ; Paul Kyzivat >>> >>> Subject: Re: New sipcore draft submission >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> On 10/24/13 4:07 PM, Andrew Allen wrote: >>>> >>>> Paul >>>> >>>> Ok >>>> >>>> So we are basically where I thought we were at when I submitted the draft. >>>> >>>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who indicates interest) can have some offline discussion in Vancouver on whether and how to progress this. >>> >>> As I indicated again on the sipcore list, I found the that the draft >>> didn't explain nearly enough to allow meaningful use of these. >>> I know you replied, and I will continue the conversation there. >>> But I will be opposed to these until and unless the draft (and notably >>> the descriptions of the tags) are clear about how one could figure out >>> what can do in the presence of the tags that one couldn't do without >>> them. AND, that the behavior that suggests doesn't "break" sip. (E.g., >>> by advocating a new and incompatible way to do something.) >>> >>> We can continue this on the sipcore list. >>> >>> Thanks, >>> Paul >>> >>>> Andrew >>>> >>>> ----- Original Message ----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >>>> To: Andrew Allen; Gonzalo Camarillo >>>> Cc: Richard Barnes (rlb@ipv.sx) ; Adam Roach >>>> (adam@nostrum.com) ; Christer Holmberg >>>> (christer.holmberg@ericsson.com) ; >>>> Mary Barnes (mary.ietf.barnes@gmail.com) >>>> Subject: Re: New sipcore draft submission >>>> draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> On 10/24/13 2:17 PM, Andrew Allen wrote: >>>>> Paul >>>>> >>>>> That is fine. Although Mary in her reply to me seemed to indicate maybe there was a possibility to use some of the DISPATCH spare time for a SIPCORE session for this. Is that a possibility? >>>>> >>>>> I already replied to your post >>>> >>>> I discussed that with Adam. We decided we can't set a precedent to >>>> spin up a session to discuss a draft that hasn't had substantial >>>> (any) list discussion. >>>> >>>> But list discussion is always welcome. >>>> >>>> Sorry, >>>> Paul >>>> >>>>> Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Sent: Thursday, October 24, 2013 1:31 PM >>>>> To: Andrew Allen; Gonzalo Camarillo >>>>> Cc: Richard Barnes (rlb@ipv.sx); Adam Roach (adam@nostrum.com); >>>>> Christer Holmberg (christer.holmberg@ericsson.com) >>>>> Subject: Re: New sipcore draft submission >>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>> >>>>> Andrew, >>>>> >>>>> I spoke with Mary about it, and we concluded that dispatch isn't right for this. (In addition to being clearly sipcore, it didn't meet the deadline for dispatch.) I was wrong to encourage you that way. >>>>> >>>>> So no official live discussion in Vancouver. (But informal >>>>> discussion >>>>> fine.) >>>>> >>>>> I'll resend my private comments to the sipcore list to kickstart some discussion there. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>>>> I just emailed Mary asking for agenda time. Should I cancel that request? >>>>>> >>>>>> -----Original Message----- >>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>>> Sent: Thursday, October 24, 2013 1:00 PM >>>>>> To: Paul Kyzivat >>>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx); Adam Roach >>>>>> (adam@nostrum.com); Christer Holmberg >>>>>> (christer.holmberg@ericsson.com) >>>>>> Subject: Re: New sipcore draft submission >>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>> >>>>>> Hi Paul, >>>>>> >>>>>> given that you think this belongs to SIPCORE, I do not see the need to run it through DISPATCH. Please, start technical discussions on the draft on the SIPCORE list. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>>>> Paul >>>>>>>> >>>>>>>> Thanks for reviewing the draft already and giving me early feedback. >>>>>>>> >>>>>>>> My responses below inline (prepended with [AA). >>>>>>>> >>>>>>>> Can I ask the ADs to determine ASAP if this needs to go to >>>>>>>> DISPATCH first or not. As outlined below my view is that it is >>>>>>>> unnecessary for every little thing to go to DISPATCH as this just >>>>>>>> creates additional delay and overhead. If it is to be discussed >>>>>>>> in DISPATCH then I definitely would want agenda time atIETF#88 for this. >>>>>>> >>>>>>> Having now seen Andrew's responses to my initial questions, I >>>>>>> think this >>>>>>> *needs* to be carefully considered by sipcore. IMO this has the >>>>>>> potential to create a dialect of sip that is incompatible with >>>>>>> normal usage. (Maybe IMS has already done that. But this will make >>>>>>> it >>>>>>> worse.) >>>>>>> >>>>>>> But if there is a desire to discuss it publicly in Vancouver then >>>>>>> dispatch is the opportunity and so some discussion on the dispatch >>>>>>> list in advance of that would be appropriate. >>>>>>> >>>>>>> I'll defer to the ADs on this. >>>>>>> >>>>>>> More inline. >>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx); Gonzalo Camarillo >>>>>>>> (Gonzalo.Camarillo@ericsson.com); Adam Roach (adam@nostrum.com) >>>>>>>> Subject: Re: New sipcore draft submission >>>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>>> >>>>>>>> Andrew, >>>>>>>> >>>>>>>> On a legalistic note, its questionable to me whether this kind of >>>>>>>> action falls within the scope of sipcore. OTOH, among existing >>>>>>>> wgs, sipcore is probably the best suited to discuss the proposal. >>>>>>>> We could take it to DISPATCH. I think DISPATCH has extra time in >>>>>>>> its agenda for Vancouver, so that might be one option for you. >>>>>>>> But then I don't know where dispatch would dispatch it. It may be >>>>>>>> that AD sponsored is the best way to go. >>>>>>>> >>>>>>>> [AA] It seemed to me that sipcore was the right place. This draft >>>>>>>> registers feature-capability indicators in a registry that was >>>>>>>> created by a sipcore RFC (RFC 6809). You could in my view make an >>>>>>>> argument that this should even have been done as part of RFC 6809. >>>>>>> >>>>>>> If this was just a matter of registering some new feature caps >>>>>>> that were not controversial, then I don't think sipcore needs to be involved. >>>>>>> >>>>>>> But as I mentioned above, I do consider these controversial. >>>>>>> >>>>>>>> Discussing it now on the dispatch list would be a good start >>>>>>>> toward discussing it at the dispatch session. >>>>>>>> >>>>>>>> [AA] Can I ask the ADs to determine if this needs to go to >>>>>>>> DISPATCH first or not. My view is that it is unnecessary for >>>>>>>> every little thing to go to DISPATCH as this just creates additional delay and overhead. >>>>>>>> This just registers some indicators in an existing IANA registry >>>>>>>> and is not (or should not be IMHO) a major project. >>>>>>> >>>>>>> To me this is a matter of whether you want to be opportunistic. >>>>>>> If this went to dispatch I would now recommend that it be >>>>>>> dispatched to sipcore. So its a matter of whether you want to talk >>>>>>> about it in the dispatch meeting. >>>>>>> >>>>>>>> Regarding substance, this draft troubles me. It takes >>>>>>>> feature-caps in exactly the direction that I found most >>>>>>>> concerning about the mechanism in the first place. >>>>>>>> >>>>>>>> Your draft partitions the existing media feature tags into two >>>>>>>> sets >>>>>>>> - those that would be useful as feature-capability-indicators, >>>>>>>> and those that aren't. But I see no explanation of the criteria >>>>>>>> used to make this distinction, nor can I think of one. >>>>>>>> >>>>>>>> [AA] I based this decision on the following criteria: If a >>>>>>>> feature tag was potentially at all useful for an intermediary to >>>>>>>> indicate it then include it in the registry. The ones not >>>>>>>> included are either directly associated with the user >>>>>>>> (intermediaries are not directly associated with the user) or >>>>>>>> would only ever have one value (e.g automata). I am not sure >>>>>>>> that every feature-capability indicator proposed to be registered >>>>>>>> is actually useful but then I don't think every media feature tag >>>>>>>> registered by RFC 3840 is either (I doubt very much if there are >>>>>>>> implementation using the sip.application or sip.control feature >>>>>>>> tags). I don't think RFC 3840 goes into a lot of details >>>>>>>> justifying of ever registered media feature tag and specifying >>>>>>>> the details of how they would be used either. I am willing to >>>>>>>> remove any feature-capability indicators that are controversial except that I think we definitely need sip.extensions, sip.methods and sip.events. >>>>>>>> There is a significant overhead to writing an >>>>>>> d progressing internet drafts so my view is lets register all that >>>>>>> might be remotely useful in the same document. >>>>>>> >>>>>>> The judgement of "useful" is reasonable. But I still can't discern >>>>>>> what the use is from the iana registration descriptions. >>>>>>> >>>>>>>> For the ones that you have requested feature capability >>>>>>>> indicators, I cannot figure out what using them would mean. For >>>>>>>> example, when I see isFocus on a Contact header I know I am in a >>>>>>>> conference, and that I can subscribe to the conference event >>>>>>>> package at the contact URI. If I see isFocus in a Feature-Caps header, what does it mean? >>>>>>>> What can I do once I know this? >>>>>>>> >>>>>>>> Section 5.14 of this draft says: >>>>>>>> >>>>>>>> This Feature-capability indicator indicates that the intermediary >>>>>>>> is a conference server, also known as a focus, and is capable of >>>>>>>> mixing together the media for all calls to the same URI. >>>>>>>> ... >>>>>>>> Examples of typical use: A conference bridge >>>>>>>> indicating that it >>>>>>>> is a conference bridge and is capable of acting as >>>>>>>> a conference >>>>>>>> focus for this session. >>>>>>>> >>>>>>>> [AA] the presence of isfocus in a Feature-Caps header field means >>>>>>>> that a UA can initiate a conference by sending a REFER request to >>>>>>>> the intermediary to invite another user and create a multi user >>>>>>>> conference from the 1-1 session. >>>>>>>> >>>>>>>> Note that Feature-Caps doesn't indicate which entity has this >>>>>>>> capability, only that something does. And since this would >>>>>>>> presumably only be used if it wasn't the UAC of the request, >>>>>>>> sending a subscribe to the contact address of the UAC wouldn't make sense. >>>>>>>> >>>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I >>>>>>>> consider this application specific and so this would be included >>>>>>>> in a feature tag registered in the global tree as stated in the >>>>>>>> draft "RFC 6809 [1] provides that addresses of intermediaries can >>>>>>>> be communicated as a value of an associated feature-capability >>>>>>>> indicator so it would be appropriate to define feature capability >>>>>>>> indicators as part of the global tree to communicate the GRUU of >>>>>>>> the intermediary and hence this is outside the scope of this >>>>>>>> document." - RFC 6809 states " If additional data about a >>>>>>>> supported feature needs to be conveyed, such as the address of >>>>>>>> the SIP entity that indicated support of the feature, then the >>>>>>>> feature definition needs to define a way to convey that >>>>>>>> information as a value of the associated feature-capability >>>>>>>> indicator." However I think the SIP specific capability >>>>>>>> indicators such as methods, extensions and events should >>>>>>>> appropriately be registered in the SIP tree not as proprietary >>>>>>>> indicator >>>>>>> s in the global tree. >>>>>>> >>>>>>> So you have defined a sip tree feature tag that is only useful in >>>>>>> conjunction with another feature tag from the global tree. >>>>>>> And the description of this feature tag doesn't even mention that. >>>>>>> >>>>>>> And this all implies a completely non-standard call model - doing >>>>>>> conferencing in a way inconsistent with RFC 4579. >>>>>>> >>>>>>> ISTM that if 4579 doesn't work for you then you should be back >>>>>>> proposing extensions/revisions to it. >>>>>>> >>>>>>>> If there is a conference bridge in the signaling path, then I >>>>>>>> would expect it to be the UAC. >>>>>>>> >>>>>>>> [AA] Although a "standard" way to invoke a conference is to send >>>>>>>> a REFER to the other UAs to invite them to the conference focus, >>>>>>>> in many deployments a scenario exists where a call involves an >>>>>>>> IP-PBX or Telephony Application Server (TAS) that can act as a >>>>>>>> focus for the conference. A participant of a call can then create >>>>>>>> a conference by sending a REFER request in dialog to the IP-PBX >>>>>>>> or TAS to use 3PCC to Invite other users to a conference. Reasons for this are 1. >>>>>>>> Not all UAs support REFER, >>>>>>> >>>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), >>>>>>> but it *could become* a focus. >>>>>>> >>>>>>> The concept that a dialog may contain intermediaries that can be >>>>>>> addressed to do stuff is not part of any sip standard that I am >>>>>>> aware of. I don't care too much as long as the "stuff" is >>>>>>> application stuff that is outside the scope of sip. But when it is >>>>>>> alternative ways to do stuff that sip supports, then I get upset. >>>>>>> >>>>>>>> 2. Many SBCs reject REFER requests going outside domains because >>>>>>>> of the potential for charging fraud (referring to a premium rate >>>>>>>> number >>>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to join >>>>>>>> the conference may be charged for initiating the call when the >>>>>>>> scenario is that the initiator of the conference should be charged. >>>>>>>> 4. No need to obtain and distribute conference URIs. >>>>>>>> Problem is how to achieve the same behavior without dialog reuse >>>>>>>> which has been deprecated by RFC 6665? >>>>>>> >>>>>>> Then maybe the problem needs to be brought up, and a standard >>>>>>> solution proposed, rather than simply enabling a proprietary mechanism. >>>>>>> >>>>>>>> As another example, consider section 5.1: >>>>>>>> >>>>>>>> Descrition: >>>>>>>> This Feature-capability indicator indicates that the intermediary >>>>>>>> supports audio as a streaming media type. >>>>>>>> ... >>>>>>>> Examples of typical use: An IP PBX indicating that it is >>>>>>>> capable of accepting and initiating sessions with audio as a >>>>>>>> streaming media type. >>>>>>>> >>>>>>>> This definition *implies* an assumption about the working >>>>>>>> environment >>>>>>>> - one that AFAIK is new. It implies that you need to know that >>>>>>>> intermediaries support a media type before you can use it. Would >>>>>>>> it be bad if there were no intermediaries, and so none indicated this? >>>>>>>> What if some intermediary *did* indicate support, but some other >>>>>>>> doesn't, but doesn't indicate that it doesn't? >>>>>>>> >>>>>>>> Bottom line: how would the presence or absence of this feature >>>>>>>> tag affect subsequent usage? >>>>>>>> >>>>>>>> [AA] The absence of the streaming types does not indicate that >>>>>>>> the intermediary does not support the media type and SDP offer >>>>>>>> answer will ultimately determine what can or cannot be used if >>>>>>>> another session is initiated involving the intermediary. However >>>>>>>> the presence of the media type in a Feature-caps header field >>>>>>>> does explictly confirm that the intermediary does support the >>>>>>>> media type and in the scenario where a UA has a choice of >>>>>>>> multiple intermediaries it could use for a conference it might >>>>>>>> choose to use the one that explicitly indicates it supports the media types the UA wants to use. >>>>>>> >>>>>>> So the UA will be able to discover that *some* intermediary >>>>>>> supports media it is interested in. And it can tell that *some* >>>>>>> intermediary says it is a focus. It doesn't know if they are the same intermediary. >>>>>>> >>>>>>> And then via some other feature tag it obtains the URI of *some* >>>>>>> intermediary on the signaling path. Or maybe it gets more than one >>>>>>> of these. >>>>>>> >>>>>>> It then makes a leap of faith and conflates all those things, to >>>>>>> determine that the URI identifies a focus that supports this media type. >>>>>>> >>>>>>> Even then, exactly what does that mean? It may or may not mean >>>>>>> that it supports mixing that media type in a conference. >>>>>>> >>>>>>>> As I stated already I don't care that much about these streaming >>>>>>>> media types. >>>>>>> >>>>>>>> I could go on, but this is enough for now. >>>>>>>> >>>>>>>> [AA] My motivation for this is that currently 3GPP are updating >>>>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>>>> >>>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with >>>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather >>>>>>>> than forwarding it all the way to the remote UA. >>>>>>> >>>>>>> And 6665 deprecates dial reuse in most of those cases. >>>>>>> Without dialog reuse, the intermediaries don't get an opportunity >>>>>>> to intercept those. >>>>>>> >>>>>>>> In order to know that an intermediary supports the target dialog >>>>>>>> mechanism needed for a REFER request sent outside the dialog to >>>>>>>> work we need sip.extensions as a feature-capability indicator. In >>>>>>>> order to know that the needed event package is supported by the >>>>>>>> intermediary so we can SUBSCROBE outside the dialog to an >>>>>>>> intermediary we need sip.events as a feature-capability indicator. >>>>>>> >>>>>>> Then I think you should be back here with a problem statement and >>>>>>> a request for how to get sip to solve it. >>>>>>> >>>>>>> And you should touch base with Christer on this. He may have a >>>>>>> different opinion on the relevance of feature-caps as a solution. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>>>> >>>>>>>>> I have submitted a new draft to sipcore to register a number of >>>>>>>>> feature capability indicators in the SIP tree (based upon some >>>>>>>>> of the existing SIP media feature tags). The draft can be found at: >>>>>>>>> >>>>>>>>>http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00. >>>>>>>>> txt >>>>>>>>> >>>>>>>>> Since there will not be a sipcore session at IETF#88 can we >>>>>>>>> have an offline discussion on how to progress this draft (which >>>>>>>>> hopefully is fairly straightforward as it just registers feature >>>>>>>>> capabilities indicators with IANA). I wouldn't want to have to >>>>>>>>> wait until March next year for a decision on progressing this. >>>>>>>>> >>>>>>>>> Andrew >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------- >>>>>>>>> --- >>>>>>>>> - >>>>>>>>> - This transmission (including any attachments) may contain >>>>>>>>> confidential information, privileged material (including >>>>>>>>> material protected by the solicitor-client or other applicable >>>>>>>>> privileges), or constitute non-public information. Any use of >>>>>>>>> this information by anyone other than the intended recipient is >>>>>>>>> prohibited. If you have received this transmission in error, >>>>>>>>> please immediately reply to the sender and delete this >>>>>>>>> information from your system. Use, dissemination, distribution, >>>>>>>>> or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>>>>>> >>>>>>>> ----------------------------------------------------------------- >>>>>>>> --- >>>>>>>> - This transmission (including any attachments) may contain >>>>>>>> confidential information, privileged material (including material >>>>>>>> protected by the solicitor-client or other applicable >>>>>>>> privileges), or constitute non-public information. Any use of >>>>>>>> this information by anyone other than the intended recipient is >>>>>>>> prohibited. If you have received this transmission in error, >>>>>>>> please immediately reply to the sender and delete this >>>>>>>> information from your system. Use, dissemination, distribution, >>>>>>>> or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> ------------------------------------------------------------------- >>>>>> -- This transmission (including any attachments) may contain >>>>>> confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately > reply to the sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission by > unintended recipients is not authorized and may be unlawful. >>>>>> >>>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> - This transmission (including any attachments) may contain >>>>> confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately > reply to the sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission by > unintended recipients is not authorized and may be unlawful. >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >>> >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >> >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From aallen@blackberry.com Fri Oct 25 13:39:03 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DB911E8204 for ; Fri, 25 Oct 2013 13:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rneq-4ukn6Dh for ; Fri, 25 Oct 2013 13:38:49 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id DEE0811E8200 for ; Fri, 25 Oct 2013 13:38:44 -0700 (PDT) Received: from xct104ads.rim.net ([10.67.111.45]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 25 Oct 2013 16:38:43 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.03.0123.003; Fri, 25 Oct 2013 15:38:42 -0500 From: Andrew Allen To: Paul Kyzivat , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cDA9i+8fOizvEqXgi8WvpARyZoF3kOw Date: Fri, 25 Oct 2013 20:38:41 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> In-Reply-To: <526AD459.1080908@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:39:03 -0000 In my view the basic premise of Feature-Caps is that an entity on the route= is indicating that it supports a particular capability. Indicating support= for features by other entities is rather problematic. I suppose a service = proxy on the route could also indicate features supported by other physical= servers that it has responsibility for that are not hosted physically by i= t. I agree with Christer that if an entity needs to support multiple sets of f= eatures that do not all apply to the same server then it should do so in se= parate Feature-Caps header fields with only the features that are all hoste= d by the same entity being included in the same Feature-Caps header field. I think entities advertising features that they are not responsible for and= have nothing to do with is bogus. Andrew -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: Friday, October 25, 2013 4:28 PM To: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators Inline. On 10/25/13 2:57 PM, Christer Holmberg wrote: > Hi, > > .... > >>> /Example:/ >>> >>> I support the find-Paul feature, and I insert a FCI: >>> >>> Feature-Caps: *, +g.find-paul=3D"sip:pkyzivat@alum.mit.edu" >>> >>> Now, in this case the address does NOT point to my entity, but to = >>> Paul's entity. My entity supports a feature, which provides Paul's addr= ess. >>> >>> So, if the FCI says: >>> >>> Feature-Caps: *, >>> +g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.methods=3D"invite" >>> >>> ...it doesn't automatically mean that I can contact Paul using INVITE. >>> By default it means that MY entity supports the INVITE method - = >>> which from the find-paul feature perspective is useless information. >>> >>> So, in the FCI specification for +g.find-paul, I would have to = >>> explictily describe how the FCI works in conjunction with other = >>> FCIs. I would have to explicitly say that, when used together = >>> +sip.methods, the >>> +sip.methods indicates which SIP methods I can use to contact Paul >>> (using the address provide in the +g.find-paul FCI). >> >> So far I agree. >> >> But suppose there is also a find-christer FCI. So we have: >> >> Feature-Caps: * >> ;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu" >> ;+g.find-paul=3D"sip:christer.holmberg@ericsson.com" >> ;+sip.methods=3D"invite" >> >> And both find-paul and find-christer want to define the use of other = >> FCIs. Then things start to become ambiguous. >> >> Should the description of find-paul specify what other FCIs "pertain" = >> to it? Or should the description of sip.methods specify what FCI(s) = >> provide the address at which it applies? Or both? What if paul and = >> christer support different methods? > > In that case you would need to have two different Feature-Caps header > fields: > > Feature-Caps: > *;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.methods=3D"invite" > Feature-Caps: > *;+g.find-paul=3D"sip:christer.holmberg@ericsson.com";+sip.methods=3D"mes= sage" That seemingly solves the problem, but if the same entity inserts them both= then its a questionable use of Feature-caps isn't it? > In your example you had two instances of the same FCI (is that even = > allowed?), I did? find-paul and find-christer are two different FCIs. (But that sort of naming will be troublesome for the registry and for the e= xpert who has to approve entries in it.:-) but there could also have been a case with two different > FCIs, both using +sip.methods, in which case you may have to put them = > into separate Feature-Caps header fields. > > These things would have to be clearly specified. Very definitely. Thanks, Paul > Regards, > > Christer > > >> Section 5.3.8 in RFC 6809 also says: >> >> "If there is additional information about the feature-capability >> indicator, it is recommended to describe such information. It c= an >> include, for example, *names of related feature-capability = >> indicators*." >> >> So, in your case, I think the +g.3gpp.see_trans FCI specifiction = >> would have to specify how the FCI is used in conjuntion with other = >> FCIs, including the +sip.method FCI. >> >> Something like: "When the session transfer request is sent to the = >> address indicated by the FCI value, the +sip.method FCI indicates = >> which SIP methods can be used." >> >> Regards, >> >> Christer >> >> >> >> *From*: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> *Sent*: Friday, October 25, 2013 12:01 PM Central Standard Time >> *To*: Andrew Allen; Paul Kyzivat ; Gonzalo = >> Camarillo >> *Cc*: rlb@ipv.sx ; adam@nostrum.com ; = >> mary.ietf.barnes@gmail.com >> *Subject*: RE: New sipcore draft submission = >> draft-allen-sipcore-sip-tree-cap-indicators >> >> Hi, >> >>>I think we can have an FCI >> >>> >> >>>Feature-Caps: *;+g.3ggp.sess_trans=3D"sip:foo@example.com;gr" >> >>> >> >>>Indicating that the entity supports 3GPP session transfer and the = >>>address where you send the session transfer request is = >>>sip:foo@example.com;gr >> >> Correct. The FCI itself indicates support of session transfer = >> feature, and the FCI value indicates the address associatd with the feat= ure. >> >>>Also if I have: >> >>> >> >>>Feature-Caps: *;+g.3ggp.sess_trans=3Dsip:foo@example.com;gr; = >>>+sip.extensions=3D"replaces, tdialog"; >> +sip.methods=3D"invite, refer, bye, options, update, prack" >> >>> >> >>> This means the entity supports 3GPP session transfer and the address wh= ere you send the session transfer request is sip:foo@example.com;gr ... >> >> Correct. >> >>> ...supports the replaces and target dialog extensions and supports the = following methods - invite, refer, bye, options, update, prack. >> >> Technically, what it means is that there is *AN* entity which = >> supports the features listed above, and the address is where you are = >> to send the session transfer request in order to trigger the 3GPP = >> session transfer feature. >> >> Regards, >> >> Christer >> >> *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> *Sent:* Friday, October 25, 2013 10:25 AM >> *To:* Paul Kyzivat; Andrew Allen; Gonzalo Camarillo >> *Cc:* rlb@ipv.sx; adam@nostrum.com; mary.ietf.barnes@gmail.com >> *Subject:* RE: New sipcore draft submission = >> draft-allen-sipcore-sip-tree-cap-indicators >> >> Hi, >> >> As Paul said, if one needs to provide address information associated = >> with a FCI, the address information cannot be a FCI of its own. It = >> needs to be a value of the FCI for which it is associated. >> >> Something like: >> >> Feature-Caps: *;+audio=3D"sip:foo@example.com" >> >> (Also note that the "+" sign is mandatory for all FCIs - no matter = >> which registry tree they belong to) >> >> Regards, >> >> Christer >> >> --------------------------------------------------------------------- >> --- >> >> *From:*Paul Kyzivat [pkyzivat@alum.mit.edu] >> *Sent:* Friday, 25 October 2013 5:06 PM >> *To:* Andrew Allen; Gonzalo Camarillo >> *Cc:* rlb@ipv.sx ; adam@nostrum.com = >> ; Christer Holmberg; = >> mary.ietf.barnes@gmail.com >> *Subject:* Re: New sipcore draft submission = >> draft-allen-sipcore-sip-tree-cap-indicators >> >> Andrew, >> >> (I see this is still on the private thread. I'll reply here, but this = >> exchange should probably be reposted to the sipcore list as part of = >> the public discussion of the draft.) >> >> On 10/24/13 10:41 PM, Andrew Allen wrote: >>> >>> Paul >>> >>> I am happy to do a revision with more details on the semantics of the c= apability indicators. However I don't think it should be held to a very muc= h higher bar than the details in RFC 3840 and the other media feature tag R= FCs regarding the meaning of thosetags. >> >> Keep in mind that the driving force for the definition of feature = >> tags in 3840 was in support of callerprefs (3841). So the context for = >> the use of feature tags was that they would be placed on Contacts in = >> REGISTER requests. So you can interpret the definitions in that = >> context: that a request sent to an AOR using callerprefs can affect = >> the choice of which device the request goes to according to the = >> capabilities it wants. In that context audio, video, isfocus all make se= nse. >> >> Their use on Contacts in dialogs was derivative to that: because = >> callerpref support is optional, there is no guarantee that the device = >> you reach via callerprefs will have the capabilities you requested. = >> So the values in the contact help confirm what you got. >> >> Of course they have since been used other ways. And the descriptions = >> of them don't necessarily reflect that. IMO that is a defect due to = >> the evolution of use. >> >> I'm looking for the same sort of context for use with the feature-caps. >> >> In private discussion you indicated to me that you expected the = >> feature caps to be grouped - with one of them giving the URI of the = >> device that the other tags apply to. I guess this would end up looking s= omething like: >> >> Feature-Caps: *;g.uri=3D"sip:foo@example.com";audio >> Feature-Caps: *;g.uri=3D"sip:bar@example.com";audio;video;isfocus >> Feature-Caps: *;g.uri=3D"sip:baz@example.com";text >> >> (I'm making up g.uri for the example.) >> >> And then presumably somebody on the signaling path will "shop" in the = >> feature caps for the capabilities it wants, and then send a request = >> to that URI, with the expectation that the UA responding will have = >> those capabilities. >> >>> The semantics should be no different than those of the corresponding e= xisting media feature tag if it is present in the Contact header. >> >> Note that 6809 says: >> >> When a SIP entity receives a SIP request, or response, that contains >> one or more Feature-Caps header fields, the feature-capability >> indicators in the header field inform the entity about the features >> and capabilities supported by entities in the SIP message signaling >> path. The procedure by which features and capabilities are invoked >> are outside the scope of this specification and MUST be described by >> individual feature-capability indicator specifications. >> >> A Feature-Caps header field value cannot convey the address of the >> SIP entity that inserted the Feature-Caps header field. If >> additional data about a supported feature needs to be conveyed, such >> as the address of the SIP entity that indicated support of the >> feature, then the feature definition needs to define a way to convey >> that information as a value of the associated feature-capability >> indicator. >> >> This was discussed at length while that RFC was under consideration. = >> Yet the definitions of the tags in *this* draft don't specify that. >> >>> The registration templates currently reference the RFC 3840 and the oth= er RFCs that define the other media feature tags that correspond to these f= eature capability indicators. >> >> And those definitions were written to be understood in the context of = >> 3840/3841. They make sense in that context, but not in *this* context. >> >> Thanks, >> Paul >> >>> But if more explicit detail is required then I can add some more text = or alternatively remove the less important ones if they are going to become= rat holes. The ones I regard as really important and urgent are sip.method= s, sip.extensions and sip.events the meaning of which I think should be q= uite clear. >>> >>> Andrew >>> >>> ----- Original Message ----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >>> To: Andrew Allen;Gonzalo.Camarillo@ericsson.com = >>> >> > > >>> Cc:rlb@ipv.sx >; >> adam@nostrum.com > >; christer.holmberg@ericsson.com = >> = >> > >; mary.ietf.barnes@gmail.com = >> > >; Paul Kyzivat = >> > >>> Subject: Re: New sipcore draft submission = >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> On 10/24/13 4:07 PM, Andrew Allen wrote: >>>> >>>> Paul >>>> >>>> Ok >>>> >>>> So we are basically where I thought we were at when I submitted the dr= aft. >>>> >>>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else wh= o indicates interest) can have some offline discussion in Vancouver on whet= her and how to progress this. >>> >>> As I indicated again on the sipcore list, I found the that the draft = >>> didn't explain nearly enough to allow meaningful use of these. >>> I know you replied, and I will continue the conversation there. >>> But I will be opposed to these until and unless the draft (and = >>> notably the descriptions of the tags) are clear about how one could = >>> figure out what can do in the presence of the tags that one couldn't = >>> do without them. AND, that the behavior that suggests doesn't = >>> "break" sip. (E.g., by advocating a new and incompatible way to do = >>> something.) >>> >>> We can continue this on the sipcore list. >>> >>> Thanks, >>> Paul >>> >>>> Andrew >>>> >>>> ----- Original Message ----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >>>> To: Andrew Allen; Gonzalo Camarillo >>> > >>>> Cc: Richard Barnes (rlb@ipv.sx ) >>> >; Adam >> Roach (adam@nostrum.com ) > >; Christer Holmberg = >> (christer.holmberg@ericsson.com = >> ) >> > >; Mary Barnes = >> (mary.ietf.barnes@gmail.com ) < = >> mary.ietf.barnes@gmail.com > >>>> Subject: Re: New sipcore draft submission = >>>> draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> On 10/24/13 2:17 PM, Andrew Allen wrote: >>>>> Paul >>>>> >>>>> That is fine. Although Mary in her reply to me seemed to indicate may= be there was a possibility to use some of the DISPATCH spare time for a SIP= CORE session for this. Is that a possibility? >>>>> >>>>> I already replied to your post >>>> >>>> I discussed that with Adam. We decided we can't set a precedent to = >>>> spin up a session to discuss a draft that hasn't had substantial = >>>> (any) list discussion. >>>> >>>> But list discussion is always welcome. >>>> >>>> Sorry, >>>> Paul >>>> >>>>> Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Sent: Thursday, October 24, 2013 1:31 PM >>>>> To: Andrew Allen; Gonzalo Camarillo >>>>> Cc: Richard Barnes (rlb@ipv.sx ); Adam Roach = >>>>> (adam@nostrum.com >> ); Christer Holmberg = >> (christer.holmberg@ericsson.com = >> ) >>>>> Subject: Re: New sipcore draft submission = >>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>> >>>>> Andrew, >>>>> >>>>> I spoke with Mary about it, and we concluded that dispatch isn't righ= t for this. (In addition to being clearly sipcore, it didn't meet the deadl= ine for dispatch.) I was wrong to encourage you that way. >>>>> >>>>> So no official live discussion in Vancouver. (But informal = >>>>> discussion >>>>> fine.) >>>>> >>>>> I'll resend my private comments to the sipcore list to kickstart some= discussion there. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>>>> I just emailed Mary asking for agenda time. Should I cancel that req= uest? >>>>>> >>>>>> -----Original Message----- >>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>>> Sent: Thursday, October 24, 2013 1:00 PM >>>>>> To: Paul Kyzivat >>>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx = >>>>>> ); Adam Roach (adam@nostrum.com = >>>>>> ); Christer Holmberg >> (christer.holmberg@ericsson.com = >> ) >>>>>> Subject: Re: New sipcore draft submission = >>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>> >>>>>> Hi Paul, >>>>>> >>>>>> given that you think this belongs to SIPCORE, I do not see the need = to run it through DISPATCH. Please, start technical discussions on the draf= t on the SIPCORE list. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>>>> Paul >>>>>>>> >>>>>>>> Thanks for reviewing the draft already and giving me early feedbac= k. >>>>>>>> >>>>>>>> My responses below inline (prepended with [AA). >>>>>>>> >>>>>>>> Can I ask the ADs to determine ASAP if this needs to go to = >>>>>>>> DISPATCH first or not. As outlined below my view is that it is = >>>>>>>> unnecessary for every little thing to go to DISPATCH as this = >>>>>>>> just creates additional delay and overhead. If it is to be = >>>>>>>> discussed in DISPATCH then I definitely would want agenda time atI= ETF#88 for this. >>>>>>> >>>>>>> Having now seen Andrew's responses to my initial questions, I = >>>>>>> think this >>>>>>> *needs* to be carefully considered by sipcore. IMO this has the = >>>>>>> potential to create a dialect of sip that is incompatible with = >>>>>>> normal usage. (Maybe IMS has already done that. But this will = >>>>>>> make it >>>>>>> worse.) >>>>>>> >>>>>>> But if there is a desire to discuss it publicly in Vancouver = >>>>>>> then dispatch is the opportunity and so some discussion on the = >>>>>>> dispatch list in advance of that would be appropriate. >>>>>>> >>>>>>> I'll defer to the ADs on this. >>>>>>> >>>>>>> More inline. >>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx = >>>>>>>> ); Gonzalo Camarillo = >>>>>>>> (Gonzalo.Camarillo@ericsson.com = >>>>>>>> ); >> Adam Roach (adam@nostrum.com ) >>>>>>>> Subject: Re: New sipcore draft submission = >>>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>>> >>>>>>>> Andrew, >>>>>>>> >>>>>>>> On a legalistic note, its questionable to me whether this kind = >>>>>>>> of action falls within the scope of sipcore. OTOH, among = >>>>>>>> existing wgs, sipcore is probably the best suited to discuss = >>>>>>>> the proposal. We could take it to DISPATCH. I think DISPATCH = >>>>>>>> has extra time in its agenda for Vancouver, so that might be = >>>>>>>> one option for you. But then I don't know where dispatch would = >>>>>>>> dispatch it. It may be that AD sponsored is the best way to go. >>>>>>>> >>>>>>>> [AA] It seemed to me that sipcore was the right place. This = >>>>>>>> draft registers feature-capability indicators in a registry = >>>>>>>> that was created by a sipcore RFC (RFC 6809). You could in my = >>>>>>>> view make an argument that this should even have been done as part= of RFC 6809. >>>>>>> >>>>>>> If this was just a matter of registering some new feature caps = >>>>>>> that were not controversial, then I don't think sipcore needs to be= involved. >>>>>>> >>>>>>> But as I mentioned above, I do consider these controversial. >>>>>>> >>>>>>>> Discussing it now on the dispatch list would be a good start = >>>>>>>> toward discussing it at the dispatch session. >>>>>>>> >>>>>>>> [AA] Can I ask the ADs to determine if this needs to go to = >>>>>>>> DISPATCH first or not. My view is that it is unnecessary for = >>>>>>>> every little thing to go to DISPATCH as this just creates addition= al delay and overhead. >>>>>>>> This just registers some indicators in an existing IANA = >>>>>>>> registry and is not (or should not be IMHO) a major project. >>>>>>> >>>>>>> To me this is a matter of whether you want to be opportunistic. >>>>>>> If this went to dispatch I would now recommend that it be = >>>>>>> dispatched to sipcore. So its a matter of whether you want to = >>>>>>> talk about it in the dispatch meeting. >>>>>>> >>>>>>>> Regarding substance, this draft troubles me. It takes = >>>>>>>> feature-caps in exactly the direction that I found most = >>>>>>>> concerning about the mechanism in the first place. >>>>>>>> >>>>>>>> Your draft partitions the existing media feature tags into two = >>>>>>>> sets >>>>>>>> - those that would be useful as feature-capability-indicators, = >>>>>>>> and those that aren't. But I see no explanation of the criteria = >>>>>>>> used to make this distinction, nor can I think of one. >>>>>>>> >>>>>>>> [AA] I based this decision on the following criteria: If a = >>>>>>>> feature tag was potentially at all useful for an intermediary = >>>>>>>> to indicate it then include it in the registry. The ones not = >>>>>>>> included are either directly associated with the user = >>>>>>>> (intermediaries are not directly associated with the user) or = >>>>>>>> would only ever have one value (e.g automata). I am not sure = >>>>>>>> that every feature-capability indicator proposed to be = >>>>>>>> registered is actually useful but then I don't think every = >>>>>>>> media feature tag registered by RFC 3840 is either (I doubt = >>>>>>>> very much if there are implementation using the sip.application = >>>>>>>> or sip.control feature tags). I don't think RFC 3840 goes into = >>>>>>>> a lot of details justifying of ever registered media feature = >>>>>>>> tag and specifying the details of how they would be used = >>>>>>>> either. I am willing to remove any feature-capability indicators = that are controversial except that I think we definitely need sip.extension= s, sip.methods and sip.events. >>>>>>>> There is a significant overhead to writing an >>>>>>> d progressing internet drafts so my view is lets register all = >>>>>>> that might be remotely useful in the same document. >>>>>>> >>>>>>> The judgement of "useful" is reasonable. But I still can't = >>>>>>> discern what the use is from the iana registration descriptions. >>>>>>> >>>>>>>> For the ones that you have requested feature capability = >>>>>>>> indicators, I cannot figure out what using them would mean. For = >>>>>>>> example, when I see isFocus on a Contact header I know I am in = >>>>>>>> a conference, and that I can subscribe to the conference event = >>>>>>>> package at the contact URI. If I see isFocus in a Feature-Caps hea= der, what does it mean? >>>>>>>> What can I do once I know this? >>>>>>>> >>>>>>>> Section 5.14 of this draft says: >>>>>>>> >>>>>>>> This Feature-capability indicator indicates that the i= ntermediary >>>>>>>> is a conference server, also known as a focus, and is = capable of >>>>>>>> mixing together the media for all calls to the same UR= I. >>>>>>>> ... >>>>>>>> Examples of typical use: A conference bridge = >>>>>>>> indicating that it >>>>>>>> is a conference bridge and is capable of acting = >>>>>>>> as a conference >>>>>>>> focus for this session. >>>>>>>> >>>>>>>> [AA] the presence of isfocus in a Feature-Caps header field = >>>>>>>> means that a UA can initiate a conference by sending a REFER = >>>>>>>> request to the intermediary to invite another user and create a = >>>>>>>> multi user conference from the 1-1 session. >>>>>>>> >>>>>>>> Note that Feature-Caps doesn't indicate which entity has this = >>>>>>>> capability, only that something does. And since this would = >>>>>>>> presumably only be used if it wasn't the UAC of the request, = >>>>>>>> sending a subscribe to the contact address of the UAC wouldn't mak= e sense. >>>>>>>> >>>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I = >>>>>>>> consider this application specific and so this would be = >>>>>>>> included in a feature tag registered in the global tree as = >>>>>>>> stated in the draft "RFC 6809 [1] provides that addresses of = >>>>>>>> intermediaries can be communicated as a value of an associated = >>>>>>>> feature-capability indicator so it would be appropriate to = >>>>>>>> define feature capability indicators as part of the global tree = >>>>>>>> to communicate the GRUU of the intermediary and hence this is = >>>>>>>> outside the scope of this document." - RFC 6809 states " If = >>>>>>>> additional data about a supported feature needs to be conveyed, = >>>>>>>> such as the address of the SIP entity that indicated support of = >>>>>>>> the feature, then the feature definition needs to define a way = >>>>>>>> to convey that information as a value of the associated = >>>>>>>> feature-capability indicator." However I think the SIP specific = >>>>>>>> capability indicators such as methods, extensions and events = >>>>>>>> should appropriately be registered in the SIP tree not as = >>>>>>>> proprietary indicator >>>>>>> s in the global tree. >>>>>>> >>>>>>> So you have defined a sip tree feature tag that is only useful = >>>>>>> in conjunction with another feature tag from the global tree. >>>>>>> And the description of this feature tag doesn't even mention that. >>>>>>> >>>>>>> And this all implies a completely non-standard call model - = >>>>>>> doing conferencing in a way inconsistent with RFC 4579. >>>>>>> >>>>>>> ISTM that if 4579 doesn't work for you then you should be back = >>>>>>> proposing extensions/revisions to it. >>>>>>> >>>>>>>> If there is a conference bridge in the signaling path, then I = >>>>>>>> would expect it to be the UAC. >>>>>>>> >>>>>>>> [AA] Although a "standard" way to invoke a conference is to = >>>>>>>> send a REFER to the other UAs to invite them to the conference = >>>>>>>> focus, in many deployments a scenario exists where a call = >>>>>>>> involves an IP-PBX or Telephony Application Server (TAS) that = >>>>>>>> can act as a focus for the conference. A participant of a call = >>>>>>>> can then create a conference by sending a REFER request in = >>>>>>>> dialog to the IP-PBX or TAS to use 3PCC to Invite other users to a= conference. Reasons for this are 1. >>>>>>>> Not all UAs support REFER, >>>>>>> >>>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), = >>>>>>> but it *could become* a focus. >>>>>>> >>>>>>> The concept that a dialog may contain intermediaries that can be = >>>>>>> addressed to do stuff is not part of any sip standard that I am = >>>>>>> aware of. I don't care too much as long as the "stuff" is = >>>>>>> application stuff that is outside the scope of sip. But when it = >>>>>>> is alternative ways to do stuff that sip supports, then I get upset. >>>>>>> >>>>>>>> 2. Many SBCs reject REFER requests going outside domains = >>>>>>>> because of the potential for charging fraud (referring to a = >>>>>>>> premium rate number >>>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to = >>>>>>>> join the conference may be charged for initiating the call = >>>>>>>> when the scenario is that the initiator of the conference should b= e charged. >>>>>>>> 4. No need to obtain and distribute conference URIs. >>>>>>>> Problem is how to achieve the same behavior without dialog = >>>>>>>> reuse which has been deprecated by RFC 6665? >>>>>>> >>>>>>> Then maybe the problem needs to be brought up, and a standard = >>>>>>> solution proposed, rather than simply enabling a proprietary mechan= ism. >>>>>>> >>>>>>>> As another example, consider section 5.1: >>>>>>>> >>>>>>>> Descrition: >>>>>>>> This Feature-capability indicator indicates that the i= ntermediary >>>>>>>> supports audio as a streaming media type. >>>>>>>> ... >>>>>>>> Examples of typical use: An IP PBX indicating that = it is >>>>>>>> capable of accepting and initiating sessions with a= udio as a >>>>>>>> streaming media type. >>>>>>>> >>>>>>>> This definition *implies* an assumption about the working = >>>>>>>> environment >>>>>>>> - one that AFAIK is new. It implies that you need to know that = >>>>>>>> intermediaries support a media type before you can use it. = >>>>>>>> Would it be bad if there were no intermediaries, and so none indic= ated this? >>>>>>>> What if some intermediary *did* indicate support, but some = >>>>>>>> other doesn't, but doesn't indicate that it doesn't? >>>>>>>> >>>>>>>> Bottom line: how would the presence or absence of this feature = >>>>>>>> tag affect subsequent usage? >>>>>>>> >>>>>>>> [AA] The absence of the streaming types does not indicate that = >>>>>>>> the intermediary does not support the media type and SDP offer = >>>>>>>> answer will ultimately determine what can or cannot be used if = >>>>>>>> another session is initiated involving the intermediary. = >>>>>>>> However the presence of the media type in a Feature-caps header = >>>>>>>> field does explictly confirm that the intermediary does support = >>>>>>>> the media type and in the scenario where a UA has a choice of = >>>>>>>> multiple intermediaries it could use for a conference it might = >>>>>>>> choose to use the one that explicitly indicates it supports the me= dia types the UA wants to use. >>>>>>> >>>>>>> So the UA will be able to discover that *some* intermediary = >>>>>>> supports media it is interested in. And it can tell that *some* = >>>>>>> intermediary says it is a focus. It doesn't know if they are the sa= me intermediary. >>>>>>> >>>>>>> And then via some other feature tag it obtains the URI of *some* = >>>>>>> intermediary on the signaling path. Or maybe it gets more than = >>>>>>> one of these. >>>>>>> >>>>>>> It then makes a leap of faith and conflates all those things, to = >>>>>>> determine that the URI identifies a focus that supports this media = type. >>>>>>> >>>>>>> Even then, exactly what does that mean? It may or may not mean = >>>>>>> that it supports mixing that media type in a conference. >>>>>>> >>>>>>>> As I stated already I don't care that much about these = >>>>>>>> streaming media types. >>>>>>> >>>>>>>> I could go on, but this is enough for now. >>>>>>>> >>>>>>>> [AA] My motivation for this is that currently 3GPP are updating = >>>>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>>>> >>>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with = >>>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather = >>>>>>>> than forwarding it all the way to the remote UA. >>>>>>> >>>>>>> And 6665 deprecates dial reuse in most of those cases. >>>>>>> Without dialog reuse, the intermediaries don't get an = >>>>>>> opportunity to intercept those. >>>>>>> >>>>>>>> In order to know that an intermediary supports the target = >>>>>>>> dialog mechanism needed for a REFER request sent outside the = >>>>>>>> dialog to work we need sip.extensions as a feature-capability = >>>>>>>> indicator. In order to know that the needed event package is = >>>>>>>> supported by the intermediary so we can SUBSCROBE outside the = >>>>>>>> dialog to an intermediary we need sip.events as a feature-capabili= ty indicator. >>>>>>> >>>>>>> Then I think you should be back here with a problem statement = >>>>>>> and a request for how to get sip to solve it. >>>>>>> >>>>>>> And you should touch base with Christer on this. He may have a = >>>>>>> different opinion on the relevance of feature-caps as a solution. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>>>> >>>>>>>>> I have submitted a new draft to sipcore to register a number = >>>>>>>>> of feature capability indicators in the SIP tree (based upon = >>>>>>>>> some of the existing SIP media feature tags). The draft can be fo= und at: >>>>>>>>> >>>>>>>>>http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators= -00. >>>>>>>>> txt >>>>>>>>> >>>>>>>>> Since there will not be a sipcore session at IETF#88 can we = >>>>>>>>> have an offline discussion on how to progress this draft = >>>>>>>>> (which hopefully is fairly straightforward as it just = >>>>>>>>> registers feature capabilities indicators with IANA). I = >>>>>>>>> wouldn't want to have to wait until March next year for a decisio= n on progressing this. >>>>>>>>> >>>>>>>>> Andrew >>>>>>>>> >>>>>>>>> -------------------------------------------------------------- >>>>>>>>> ----- >>>>>>>>> - >>>>>>>>> - This transmission (including any attachments) may contain = >>>>>>>>> confidential information, privileged material (including = >>>>>>>>> material protected by the solicitor-client or other applicable = >>>>>>>>> privileges), or constitute non-public information. Any use of = >>>>>>>>> this information by anyone other than the intended recipient = >>>>>>>>> is prohibited. If you have received this transmission in = >>>>>>>>> error, please immediately reply to the sender and delete this = >>>>>>>>> information from your system. Use, dissemination, = >>>>>>>>> distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful. >>>>>>>> >>>>>>>> --------------------------------------------------------------- >>>>>>>> ----- >>>>>>>> - This transmission (including any attachments) may contain = >>>>>>>> confidential information, privileged material (including = >>>>>>>> material protected by the solicitor-client or other applicable = >>>>>>>> privileges), or constitute non-public information. Any use of = >>>>>>>> this information by anyone other than the intended recipient is = >>>>>>>> prohibited. If you have received this transmission in error, = >>>>>>>> please immediately reply to the sender and delete this = >>>>>>>> information from your system. Use, dissemination, distribution, = >>>>>>>> or reproduction of this transmission by unintended recipients is n= ot authorized and may be unlawful. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> ----------------------------------------------------------------- >>>>>> ---- This transmission (including any attachments) may contain = >>>>>> confidential information, privileged material (including material = >>>>>> protected by the solicitor-client or other applicable = >>>>>> privileges), or constitute non-public information. Any use of = >>>>>> this informationby anyone other than the intended recipient is = >>>>>> prohibited. If you have >> received this transmission in error, please immediately reply to the = >> sender and delete this information from your system. Use, = >> dissemination, distribution, or reproduction of this transmission by = >> unintended recipients is not authorized and may be unlawful. >>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------ >>>>> --- This transmission (including any attachments) may contain = >>>>> confidential information, privileged material (including material = >>>>> protected by the solicitor-client or other applicable privileges), = >>>>> or constitute non-public information. Any use of this = >>>>> informationby anyone other than the intended recipient is = >>>>> prohibited. If you have >> received this transmission in error, please immediately reply to the = >> sender and delete this information from your system. Use, = >> dissemination, distribution, or reproduction of this transmission by = >> unintended recipients is not authorized and may be unlawful. >>>>> >>>>> >>>> >>>> ------------------------------------------------------------------- >>>> -- This transmission (including any attachments) may contain = >>>> confidential information, privileged material (including material = >>>> protected by the solicitor-client or other applicable privileges), = >>>> or constitute non-public information. Any use of this informationby = >>>> anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the = >> sender and delete this information from your system. Use, = >> dissemination, distribution, or reproduction of this transmission by = >> unintended recipients is not authorized and may be unlawful. >>>> >>>> >>> >>> -------------------------------------------------------------------- >>> - This transmission (including any attachments) may contain = >>> confidential information, privileged material (including material = >>> protected by the solicitor-client or other applicable privileges), = >>> or constitute non-public information. Any use of this informationby = >>> anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the = >> sender and delete this information from your system. Use, = >> dissemination, distribution, or reproduction of this transmission by = >> unintended recipients is not authorized and may be unlawful. >>> >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain = >> confidential information, privileged material (including material = >> protected by the solicitor-client or other applicable privileges), or = >> constitute non-public information. Any use of this information by = >> anyone other than the intended recipient is prohibited. If you have = >> received this transmission in error, please immediately reply to the = >> sender and delete this information from your system. Use, = >> dissemination, distribution, or reproduction of this transmission by = >> unintended recipients is not authorized and may be unlawful. >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain = >> confidential information, privileged material (including material = >> protected by the solicitor-client or other applicable privileges), or = >> constitute non-public information. Any use of this information by = >> anyone other than the intended recipient is prohibited. If you have = >> received this transmission in error, please immediately reply to the = >> sender and delete this information from your system. Use, = >> dissemination, distribution, or reproduction of this transmission by = >> unintended recipients is not authorized and may be unlawful. >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Fri Oct 25 13:47:19 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA3611E820B for ; Fri, 25 Oct 2013 13:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=-1.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xenM1q4Q45x1 for ; Fri, 25 Oct 2013 13:47:10 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4106E11E8202 for ; Fri, 25 Oct 2013 13:47:07 -0700 (PDT) X-AuditID: c1b4fb38-b7f178e00000233b-94-526ad8c8254b Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 78.02.09019.8C8DA625; Fri, 25 Oct 2013 22:47:04 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Fri, 25 Oct 2013 22:47:04 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cC6biarXkjwHUyLjbPr0puRmZoF4NQegAACZXY= Date: Fri, 25 Oct 2013 20:47:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F733A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se>, <526AD459.1080908@alum.mit.edu> In-Reply-To: <526AD459.1080908@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4F733AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvje6JG1lBBu3TpS1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjx6F29oLNrhU/P5Q1MN6x6mLk5JAQMJHo nrufFcIWk7hwbz1bFyMXh5DAUUaJey+vMkI4SxglOlqPM3UxcnCwCVhIdP/TBmkQEQiUuLpk AjOILSyQKHHu+F5GiHiSxN8V19kgbCuJnwtfgS1gEVCVuHp7MivIGF4BX4k1h40gxl9lktg8 YxJYDaeAjsSt3fvZQWxGoIO+n1rDBGIzC4hL3HoynwniUAGJJXvOM0PYohIvH/+DekBJ4seG SywQ9fkSJxcfAKvhFRCUODnzCcsERpFZSEbNQlI2C0kZRFxP4sbUKWwQtrbEsoWvmSFsXYkZ /w5B1VhL3Nn7hB1ZzQJGjlWMHMWpxUm56UYGmxiBMXVwy2+LHYyX/9ocYpTmYFES5/341jlI SCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+N5dd4MJTmZJA1fjthLRyZzblx4+9NW6c0fFmUt OntIuFIhtmCl+peTz0W3X1kTu6UnPFiDwTQ9pzU4pO1tqi37T8fH0pz5l92YTPc7WE2PWHf/ dKkq5/WImilSxuf23PTofdppkLpcq+3xLlOJtzvFuR6cnhXPtVWxT2/a+3i1yGshLUtFXiix FGckGmoxFxUnAgC5BDiFdwIAAA== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:47:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4F733AESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >>>> /Example:/ >>>> >>>> I support the find-Paul feature, and I insert a FCI: >>>> >>>> Feature-Caps: *, +g.find-paul=3D"sip:pkyzivat@alum.mit.edu" >>>> >>>> Now, in this case the address does NOT point to my entity, but to Paul= 's >>>> entity. My entity supports a feature, which provides Paul's address. >>>> >>>> So, if the FCI says: >>>> >>>> Feature-Caps: *, >>>> +g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.methods=3D"invite" >>>> >>>> ...it doesn't automatically mean that I can contact Paul using INVITE. >>>> By default it means that MY entity supports the INVITE method - which >>>> from the find-paul feature perspective is useless information. >>>> >>>> So, in the FCI specification for +g.find-paul, I would have to >>>> explictily describe how the FCI works in conjunction with other FCIs. = I >>>> would have to explicitly say that, when used together +sip.methods, th= e >>>> +sip.methods indicates which SIP methods I can use to contact Paul >>>> (using the address provide in the +g.find-paul FCI). >>> >>> So far I agree. >>> >>> But suppose there is also a find-christer FCI. So we have: >>> >>> Feature-Caps: * >>> ;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu" >>> ;+g.find-paul=3D"sip:christer.holmberg@ericsson.com" >>> ;+sip.methods=3D"invite" >>> >>> And both find-paul and find-christer want to define the use of other >>> FCIs. Then things start to become ambiguous. >>> >>> Should the description of find-paul specify what other FCIs "pertain" t= o >>> it? Or should the description of sip.methods specify what FCI(s) provid= e >>> the address at which it applies? Or both? What if paul and christer >>> support different methods? >> >> In that case you would need to have two different Feature-Caps header >> fields: >> >> Feature-Caps: >> *;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.methods=3D"invite" >> Feature-Caps: >> *;+g.find-paul=3D"sip:christer.holmberg@ericsson.com";+sip.methods=3D"me= ssage" > > That seemingly solves the problem, but if the same entity inserts them > both then its a questionable use of Feature-caps isn't it? I am not sure. In fact, I think it even more highlights the fact that the F= CI mechanism itself doesn't say anything about which entity supports the li= sted features. It only says that AN entity supports them, and two "AN entit= y" could be the same "AN entity" :) >> In your example you had two instances of the same FCI (is that even >> allowed?), > > I did? find-paul and find-christer are two different FCIs. Yes, but there was no find-christer in your example :) > (But that sort of naming will be troublesome for the registry and for > the expert who has to approve entries in it.:-) Sure. A more realistic example could be e.g. find-helpdesk, which is provid= ed to you when you call into a conference. Then, if you have a problem with= the conference, you could call the helpdesk to ask for help. And, again, t= hat could be a different entity than the one who indicated support of the f= eature. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4F733AESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

 

>>>> /Exam= ple:/
>>>>
>>>> I support the find-Paul feature, and I insert a FCI:
>>>>
>>>>      Feature-Caps: *, +g.find= -paul=3D"sip:pkyzivat@alum.mit.edu"
>>>>
>>>> Now, in this case the address does NOT point to my entity,= but to Paul's
>>>> entity. My entity supports a feature, which provides Paul'= s address.
>>>>
>>>> So, if the FCI says:
>>>>
>>>>      Feature-Caps: *,
>>>> +g.find-paul=3D"sip:pkyzivat@alum.mit.edu";&= #43;sip.methods=3D"invite"
>>>>
>>>> ...it doesn't automatically mean that I can contact Paul u= sing INVITE.
>>>> By default it means that MY entity supports the INVITE met= hod - which
>>>> from the find-paul feature perspective is useless informat= ion.
>>>>
>>>> So, in the FCI specification for +g.find-paul, I would= have to
>>>> explictily describe how the FCI works in conjunction with = other FCIs. I
>>>> would have to explicitly say that, when used together += ;sip.methods, the
>>>> +sip.methods indicates which SIP methods I can use to = contact Paul
>>>> (using the address provide in the +g.find-paul FCI). >>>
>>> So far I agree.
>>>
>>> But suppose there is also a find-christer FCI. So we have:
>>>
>>> Feature-Caps: *
>>>    ;+g.find-paul=3D"sip:pkyzivat@alum.= mit.edu"
>>>    ;+g.find-paul=3D"sip:christer.holmb= erg@ericsson.com"
>>>    ;+sip.methods=3D"invite"
>>>
>>> And both find-paul and find-christer want to define the use of= other
>>> FCIs. Then things start to become ambiguous.
>>>
>>> Should the description of find-paul specify what other FCIs &q= uot;pertain" to
>>> it? Or should the description of sip.methods specify what FCI(= s) provide
>>> the address at which it applies? Or both? What if paul and chr= ister
>>> support different methods?
>>
>> In that case you would need to have two different Feature-Caps hea= der
>> fields:
>>
>>      Feature-Caps:
>> *;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+si= p.methods=3D"invite"
>>      Feature-Caps:
>> *;+g.find-paul=3D"sip:christer.holmberg@ericsson.com"= ;;+sip.methods=3D"message"
>
> That seemingly solves the problem, but if the same entity inserts them=
> both then its a questionable use of Feature-caps isn't it?

 

I am not sure. In fact= , I think it even more highlights the fact that the FCI mechanism itself do= esn't say anything about which entity supports the listed features. It only= says that AN entity supports them, and two "AN entity" could be the same "AN entity"=  :)


>> In your example you had two instances of the same FCI (is that eve= n
>> allowed?),
>
> I did? find-paul and find-christer are two different FCIs.

 

Yes, but there was no find-christer in your example :)


> (But that sort of naming will be troublesome for the registry and for =
> the expert who has to approve entries in it.:-)

 

Sure. A more realistic example could be e.g. find-helpdesk, which is pro= vided to you when you call into a conference. Then, if you have a= problem with the conference, you could call the helpdesk to ask for help. = And, again, that could be a different entity than the one who indicated support of the feature.

 

Regards,

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C4F733AESESSMB209erics_-- From pkyzivat@alum.mit.edu Fri Oct 25 13:50:37 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9053D11E8179 for ; Fri, 25 Oct 2013 13:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.644 X-Spam-Level: X-Spam-Status: No, score=0.644 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muZYio6yKzqO for ; Fri, 25 Oct 2013 13:50:32 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 600D611E81ED for ; Fri, 25 Oct 2013 13:50:23 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta02.westchester.pa.mail.comcast.net with comcast id hXKk1m00A0mv7h051YqNjA; Fri, 25 Oct 2013 20:50:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id hYqN1m00A3ZTu2S3XYqNBd; Fri, 25 Oct 2013 20:50:22 +0000 Message-ID: <526AD98E.5000907@alum.mit.edu> Date: Fri, 25 Oct 2013 16:50:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Andrew Allen , Christer Holmberg , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382734222; bh=kmFSdsem8xZsD/m6XNitf0pOKzl2j0nrdZP82HM9NiY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YlEWeCvtSc1R5yMaHMHSm+RUQFUAzGPzFt6XFypik7cHiT4mLvDuv85P4VACeef4F kRIEoIFhKc4pKqp8LrRPXKELXnpydcAqfyFRBrzGvwrbUIg4lqrD7/jm4NPUS8Zx52 wHdMksykrVRDrYE86o3m/r//0I9E7a1/jvWxvljHw1IJEAl/+x+pc0k2EJ8LDqpqW6 bV1rVUvfedhLE6bCUCqGmEh+Jzq901xyjU5t27aloKL4lDPmm6BrCG4Yxzo9L66hyq R1E8b6bSwITgr8YE3XpofVs+yXLOpn64EC/94dbs4r2UrBTgi2IMhHOxxgKXtid955 zB3QiNE/wOyXQ== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:50:37 -0000 On 10/25/13 4:38 PM, Andrew Allen wrote: > > In my view the basic premise of Feature-Caps is that an entity on the route is indicating that it supports a particular capability. Indicating support for features by other entities is rather problematic. I suppose a service proxy on the route could also indicate features supported by other physical servers that it has responsibility for that are not hosted physically by it. It was also a basic premise of feature-caps that it didn't specify the address of the thing reporting the capabilities. The explanation at the time was that it wasn't necessary - that it was only necessary that there was something on the path that had those capabilities. > I agree with Christer that if an entity needs to support multiple sets of features that do not all apply to the same server then it should do so in separate Feature-Caps header fields with only the features that are all hosted by the same entity being included in the same Feature-Caps header field. > > I think entities advertising features that they are not responsible for and have nothing to do with is bogus. I agree with that. Then what does it mean for something on the path to insert an FCI containing a URI? That seems ok as long as you don't infer that other FCIs with it apply to the thing with that URI. Thanks, Paul > Andrew > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, October 25, 2013 4:28 PM > To: Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators > > Inline. > > On 10/25/13 2:57 PM, Christer Holmberg wrote: >> Hi, >> >> .... >> >>>> /Example:/ >>>> >>>> I support the find-Paul feature, and I insert a FCI: >>>> >>>> Feature-Caps: *, +g.find-paul="sip:pkyzivat@alum.mit.edu" >>>> >>>> Now, in this case the address does NOT point to my entity, but to >>>> Paul's entity. My entity supports a feature, which provides Paul's address. >>>> >>>> So, if the FCI says: >>>> >>>> Feature-Caps: *, >>>> +g.find-paul="sip:pkyzivat@alum.mit.edu";+sip.methods="invite" >>>> >>>> ...it doesn't automatically mean that I can contact Paul using INVITE. >>>> By default it means that MY entity supports the INVITE method - >>>> which from the find-paul feature perspective is useless information. >>>> >>>> So, in the FCI specification for +g.find-paul, I would have to >>>> explictily describe how the FCI works in conjunction with other >>>> FCIs. I would have to explicitly say that, when used together >>>> +sip.methods, the >>>> +sip.methods indicates which SIP methods I can use to contact Paul >>>> (using the address provide in the +g.find-paul FCI). >>> >>> So far I agree. >>> >>> But suppose there is also a find-christer FCI. So we have: >>> >>> Feature-Caps: * >>> ;+g.find-paul="sip:pkyzivat@alum.mit.edu" >>> ;+g.find-paul="sip:christer.holmberg@ericsson.com" >>> ;+sip.methods="invite" >>> >>> And both find-paul and find-christer want to define the use of other >>> FCIs. Then things start to become ambiguous. >>> >>> Should the description of find-paul specify what other FCIs "pertain" >>> to it? Or should the description of sip.methods specify what FCI(s) >>> provide the address at which it applies? Or both? What if paul and >>> christer support different methods? >> >> In that case you would need to have two different Feature-Caps header >> fields: >> >> Feature-Caps: >> *;+g.find-paul="sip:pkyzivat@alum.mit.edu";+sip.methods="invite" >> Feature-Caps: >> *;+g.find-paul="sip:christer.holmberg@ericsson.com";+sip.methods="message" > > That seemingly solves the problem, but if the same entity inserts them both then its a questionable use of Feature-caps isn't it? > >> In your example you had two instances of the same FCI (is that even >> allowed?), > > I did? find-paul and find-christer are two different FCIs. > (But that sort of naming will be troublesome for the registry and for the expert who has to approve entries in it.:-) > > but there could also have been a case with two different >> FCIs, both using +sip.methods, in which case you may have to put them >> into separate Feature-Caps header fields. >> >> These things would have to be clearly specified. > > Very definitely. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> >>> Section 5.3.8 in RFC 6809 also says: >>> >>> "If there is additional information about the feature-capability >>> indicator, it is recommended to describe such information. It can >>> include, for example, *names of related feature-capability >>> indicators*." >>> >>> So, in your case, I think the +g.3gpp.see_trans FCI specifiction >>> would have to specify how the FCI is used in conjuntion with other >>> FCIs, including the +sip.method FCI. >>> >>> Something like: "When the session transfer request is sent to the >>> address indicated by the FCI value, the +sip.method FCI indicates >>> which SIP methods can be used." >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> *From*: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> *Sent*: Friday, October 25, 2013 12:01 PM Central Standard Time >>> *To*: Andrew Allen; Paul Kyzivat ; Gonzalo >>> Camarillo >>> *Cc*: rlb@ipv.sx ; adam@nostrum.com ; >>> mary.ietf.barnes@gmail.com >>> *Subject*: RE: New sipcore draft submission >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> Hi, >>> >>>> I think we can have an FCI >>> >>>> >>> >>>> Feature-Caps: *;+g.3ggp.sess_trans="sip:foo@example.com;gr" >>> >>>> >>> >>>> Indicating that the entity supports 3GPP session transfer and the >>>> address where you send the session transfer request is >>>> sip:foo@example.com;gr >>> >>> Correct. The FCI itself indicates support of session transfer >>> feature, and the FCI value indicates the address associatd with the feature. >>> >>>> Also if I have: >>> >>>> >>> >>>> Feature-Caps: *;+g.3ggp.sess_trans=sip:foo@example.com;gr; >>>> +sip.extensions="replaces, tdialog"; >>> +sip.methods="invite, refer, bye, options, update, prack" >>> >>>> >>> >>>> This means the entity supports 3GPP session transfer and the address where you send the session transfer request is sip:foo@example.com;gr ... >>> >>> Correct. >>> >>>> ...supports the replaces and target dialog extensions and supports the following methods - invite, refer, bye, options, update, prack. >>> >>> Technically, what it means is that there is *AN* entity which >>> supports the features listed above, and the address is where you are >>> to send the session transfer request in order to trigger the 3GPP >>> session transfer feature. >>> >>> Regards, >>> >>> Christer >>> >>> *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> *Sent:* Friday, October 25, 2013 10:25 AM >>> *To:* Paul Kyzivat; Andrew Allen; Gonzalo Camarillo >>> *Cc:* rlb@ipv.sx; adam@nostrum.com; mary.ietf.barnes@gmail.com >>> *Subject:* RE: New sipcore draft submission >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> Hi, >>> >>> As Paul said, if one needs to provide address information associated >>> with a FCI, the address information cannot be a FCI of its own. It >>> needs to be a value of the FCI for which it is associated. >>> >>> Something like: >>> >>> Feature-Caps: *;+audio="sip:foo@example.com" >>> >>> (Also note that the "+" sign is mandatory for all FCIs - no matter >>> which registry tree they belong to) >>> >>> Regards, >>> >>> Christer >>> >>> --------------------------------------------------------------------- >>> --- >>> >>> *From:*Paul Kyzivat [pkyzivat@alum.mit.edu] >>> *Sent:* Friday, 25 October 2013 5:06 PM >>> *To:* Andrew Allen; Gonzalo Camarillo >>> *Cc:* rlb@ipv.sx ; adam@nostrum.com >>> ; Christer Holmberg; >>> mary.ietf.barnes@gmail.com >>> *Subject:* Re: New sipcore draft submission >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> Andrew, >>> >>> (I see this is still on the private thread. I'll reply here, but this >>> exchange should probably be reposted to the sipcore list as part of >>> the public discussion of the draft.) >>> >>> On 10/24/13 10:41 PM, Andrew Allen wrote: >>>> >>>> Paul >>>> >>>> I am happy to do a revision with more details on the semantics of the capability indicators. However I don't think it should be held to a very much higher bar than the details in RFC 3840 and the other media feature tag RFCs regarding the meaning of thosetags. >>> >>> Keep in mind that the driving force for the definition of feature >>> tags in 3840 was in support of callerprefs (3841). So the context for >>> the use of feature tags was that they would be placed on Contacts in >>> REGISTER requests. So you can interpret the definitions in that >>> context: that a request sent to an AOR using callerprefs can affect >>> the choice of which device the request goes to according to the >>> capabilities it wants. In that context audio, video, isfocus all make sense. >>> >>> Their use on Contacts in dialogs was derivative to that: because >>> callerpref support is optional, there is no guarantee that the device >>> you reach via callerprefs will have the capabilities you requested. >>> So the values in the contact help confirm what you got. >>> >>> Of course they have since been used other ways. And the descriptions >>> of them don't necessarily reflect that. IMO that is a defect due to >>> the evolution of use. >>> >>> I'm looking for the same sort of context for use with the feature-caps. >>> >>> In private discussion you indicated to me that you expected the >>> feature caps to be grouped - with one of them giving the URI of the >>> device that the other tags apply to. I guess this would end up looking something like: >>> >>> Feature-Caps: *;g.uri="sip:foo@example.com";audio >>> Feature-Caps: *;g.uri="sip:bar@example.com";audio;video;isfocus >>> Feature-Caps: *;g.uri="sip:baz@example.com";text >>> >>> (I'm making up g.uri for the example.) >>> >>> And then presumably somebody on the signaling path will "shop" in the >>> feature caps for the capabilities it wants, and then send a request >>> to that URI, with the expectation that the UA responding will have >>> those capabilities. >>> >>>> The semantics should be no different than those of the corresponding existing media feature tag if it is present in the Contact header. >>> >>> Note that 6809 says: >>> >>> When a SIP entity receives a SIP request, or response, that contains >>> one or more Feature-Caps header fields, the feature-capability >>> indicators in the header field inform the entity about the features >>> and capabilities supported by entities in the SIP message signaling >>> path. The procedure by which features and capabilities are invoked >>> are outside the scope of this specification and MUST be described by >>> individual feature-capability indicator specifications. >>> >>> A Feature-Caps header field value cannot convey the address of the >>> SIP entity that inserted the Feature-Caps header field. If >>> additional data about a supported feature needs to be conveyed, such >>> as the address of the SIP entity that indicated support of the >>> feature, then the feature definition needs to define a way to convey >>> that information as a value of the associated feature-capability >>> indicator. >>> >>> This was discussed at length while that RFC was under consideration. >>> Yet the definitions of the tags in *this* draft don't specify that. >>> >>>> The registration templates currently reference the RFC 3840 and the other RFCs that define the other media feature tags that correspond to these feature capability indicators. >>> >>> And those definitions were written to be understood in the context of >>> 3840/3841. They make sense in that context, but not in *this* context. >>> >>> Thanks, >>> Paul >>> >>>> But if more explicit detail is required then I can add some more text or alternatively remove the less important ones if they are going to become rat holes. The ones I regard as really important and urgent are sip.methods, sip.extensions and sip.events the meaning of which I think should be quite clear. >>>> >>>> Andrew >>>> >>>> ----- Original Message ----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >>>> To: Andrew Allen;Gonzalo.Camarillo@ericsson.com >>>> >>> >> > >>>> Cc:rlb@ipv.sx >; >>> adam@nostrum.com >> >; christer.holmberg@ericsson.com >>> >>> >> >; mary.ietf.barnes@gmail.com >>> >> >; Paul Kyzivat >>> > >>>> Subject: Re: New sipcore draft submission >>>> draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> On 10/24/13 4:07 PM, Andrew Allen wrote: >>>>> >>>>> Paul >>>>> >>>>> Ok >>>>> >>>>> So we are basically where I thought we were at when I submitted the draft. >>>>> >>>>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else who indicates interest) can have some offline discussion in Vancouver on whether and how to progress this. >>>> >>>> As I indicated again on the sipcore list, I found the that the draft >>>> didn't explain nearly enough to allow meaningful use of these. >>>> I know you replied, and I will continue the conversation there. >>>> But I will be opposed to these until and unless the draft (and >>>> notably the descriptions of the tags) are clear about how one could >>>> figure out what can do in the presence of the tags that one couldn't >>>> do without them. AND, that the behavior that suggests doesn't >>>> "break" sip. (E.g., by advocating a new and incompatible way to do >>>> something.) >>>> >>>> We can continue this on the sipcore list. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Andrew >>>>> >>>>> ----- Original Message ----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >>>>> To: Andrew Allen; Gonzalo Camarillo >>>> > >>>>> Cc: Richard Barnes (rlb@ipv.sx ) >>>> >; Adam >>> Roach (adam@nostrum.com ) >> >; Christer Holmberg >>> (christer.holmberg@ericsson.com >>> ) >>> >> >; Mary Barnes >>> (mary.ietf.barnes@gmail.com ) < >>> mary.ietf.barnes@gmail.com > >>>>> Subject: Re: New sipcore draft submission >>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>> >>>>> On 10/24/13 2:17 PM, Andrew Allen wrote: >>>>>> Paul >>>>>> >>>>>> That is fine. Although Mary in her reply to me seemed to indicate maybe there was a possibility to use some of the DISPATCH spare time for a SIPCORE session for this. Is that a possibility? >>>>>> >>>>>> I already replied to your post >>>>> >>>>> I discussed that with Adam. We decided we can't set a precedent to >>>>> spin up a session to discuss a draft that hasn't had substantial >>>>> (any) list discussion. >>>>> >>>>> But list discussion is always welcome. >>>>> >>>>> Sorry, >>>>> Paul >>>>> >>>>>> Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>> Sent: Thursday, October 24, 2013 1:31 PM >>>>>> To: Andrew Allen; Gonzalo Camarillo >>>>>> Cc: Richard Barnes (rlb@ipv.sx ); Adam Roach >>>>>> (adam@nostrum.com >>> ); Christer Holmberg >>> (christer.holmberg@ericsson.com >>> ) >>>>>> Subject: Re: New sipcore draft submission >>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>> >>>>>> Andrew, >>>>>> >>>>>> I spoke with Mary about it, and we concluded that dispatch isn't right for this. (In addition to being clearly sipcore, it didn't meet the deadline for dispatch.) I was wrong to encourage you that way. >>>>>> >>>>>> So no official live discussion in Vancouver. (But informal >>>>>> discussion >>>>>> fine.) >>>>>> >>>>>> I'll resend my private comments to the sipcore list to kickstart some discussion there. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>>>>> I just emailed Mary asking for agenda time. Should I cancel that request? >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>>>> Sent: Thursday, October 24, 2013 1:00 PM >>>>>>> To: Paul Kyzivat >>>>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx >>>>>>> ); Adam Roach (adam@nostrum.com >>>>>>> ); Christer Holmberg >>> (christer.holmberg@ericsson.com >>> ) >>>>>>> Subject: Re: New sipcore draft submission >>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>> >>>>>>> Hi Paul, >>>>>>> >>>>>>> given that you think this belongs to SIPCORE, I do not see the need to run it through DISPATCH. Please, start technical discussions on the draft on the SIPCORE list. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Gonzalo >>>>>>> >>>>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> Thanks for reviewing the draft already and giving me early feedback. >>>>>>>>> >>>>>>>>> My responses below inline (prepended with [AA). >>>>>>>>> >>>>>>>>> Can I ask the ADs to determine ASAP if this needs to go to >>>>>>>>> DISPATCH first or not. As outlined below my view is that it is >>>>>>>>> unnecessary for every little thing to go to DISPATCH as this >>>>>>>>> just creates additional delay and overhead. If it is to be >>>>>>>>> discussed in DISPATCH then I definitely would want agenda time atIETF#88 for this. >>>>>>>> >>>>>>>> Having now seen Andrew's responses to my initial questions, I >>>>>>>> think this >>>>>>>> *needs* to be carefully considered by sipcore. IMO this has the >>>>>>>> potential to create a dialect of sip that is incompatible with >>>>>>>> normal usage. (Maybe IMS has already done that. But this will >>>>>>>> make it >>>>>>>> worse.) >>>>>>>> >>>>>>>> But if there is a desire to discuss it publicly in Vancouver >>>>>>>> then dispatch is the opportunity and so some discussion on the >>>>>>>> dispatch list in advance of that would be appropriate. >>>>>>>> >>>>>>>> I'll defer to the ADs on this. >>>>>>>> >>>>>>>> More inline. >>>>>>>> >>>>>>>>> Andrew >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx >>>>>>>>> ); Gonzalo Camarillo >>>>>>>>> (Gonzalo.Camarillo@ericsson.com >>>>>>>>> ); >>> Adam Roach (adam@nostrum.com ) >>>>>>>>> Subject: Re: New sipcore draft submission >>>>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>>>> >>>>>>>>> Andrew, >>>>>>>>> >>>>>>>>> On a legalistic note, its questionable to me whether this kind >>>>>>>>> of action falls within the scope of sipcore. OTOH, among >>>>>>>>> existing wgs, sipcore is probably the best suited to discuss >>>>>>>>> the proposal. We could take it to DISPATCH. I think DISPATCH >>>>>>>>> has extra time in its agenda for Vancouver, so that might be >>>>>>>>> one option for you. But then I don't know where dispatch would >>>>>>>>> dispatch it. It may be that AD sponsored is the best way to go. >>>>>>>>> >>>>>>>>> [AA] It seemed to me that sipcore was the right place. This >>>>>>>>> draft registers feature-capability indicators in a registry >>>>>>>>> that was created by a sipcore RFC (RFC 6809). You could in my >>>>>>>>> view make an argument that this should even have been done as part of RFC 6809. >>>>>>>> >>>>>>>> If this was just a matter of registering some new feature caps >>>>>>>> that were not controversial, then I don't think sipcore needs to be involved. >>>>>>>> >>>>>>>> But as I mentioned above, I do consider these controversial. >>>>>>>> >>>>>>>>> Discussing it now on the dispatch list would be a good start >>>>>>>>> toward discussing it at the dispatch session. >>>>>>>>> >>>>>>>>> [AA] Can I ask the ADs to determine if this needs to go to >>>>>>>>> DISPATCH first or not. My view is that it is unnecessary for >>>>>>>>> every little thing to go to DISPATCH as this just creates additional delay and overhead. >>>>>>>>> This just registers some indicators in an existing IANA >>>>>>>>> registry and is not (or should not be IMHO) a major project. >>>>>>>> >>>>>>>> To me this is a matter of whether you want to be opportunistic. >>>>>>>> If this went to dispatch I would now recommend that it be >>>>>>>> dispatched to sipcore. So its a matter of whether you want to >>>>>>>> talk about it in the dispatch meeting. >>>>>>>> >>>>>>>>> Regarding substance, this draft troubles me. It takes >>>>>>>>> feature-caps in exactly the direction that I found most >>>>>>>>> concerning about the mechanism in the first place. >>>>>>>>> >>>>>>>>> Your draft partitions the existing media feature tags into two >>>>>>>>> sets >>>>>>>>> - those that would be useful as feature-capability-indicators, >>>>>>>>> and those that aren't. But I see no explanation of the criteria >>>>>>>>> used to make this distinction, nor can I think of one. >>>>>>>>> >>>>>>>>> [AA] I based this decision on the following criteria: If a >>>>>>>>> feature tag was potentially at all useful for an intermediary >>>>>>>>> to indicate it then include it in the registry. The ones not >>>>>>>>> included are either directly associated with the user >>>>>>>>> (intermediaries are not directly associated with the user) or >>>>>>>>> would only ever have one value (e.g automata). I am not sure >>>>>>>>> that every feature-capability indicator proposed to be >>>>>>>>> registered is actually useful but then I don't think every >>>>>>>>> media feature tag registered by RFC 3840 is either (I doubt >>>>>>>>> very much if there are implementation using the sip.application >>>>>>>>> or sip.control feature tags). I don't think RFC 3840 goes into >>>>>>>>> a lot of details justifying of ever registered media feature >>>>>>>>> tag and specifying the details of how they would be used >>>>>>>>> either. I am willing to remove any feature-capability indicators that are controversial except that I think we definitely need sip.extensions, sip.methods and sip.events. >>>>>>>>> There is a significant overhead to writing an >>>>>>>> d progressing internet drafts so my view is lets register all >>>>>>>> that might be remotely useful in the same document. >>>>>>>> >>>>>>>> The judgement of "useful" is reasonable. But I still can't >>>>>>>> discern what the use is from the iana registration descriptions. >>>>>>>> >>>>>>>>> For the ones that you have requested feature capability >>>>>>>>> indicators, I cannot figure out what using them would mean. For >>>>>>>>> example, when I see isFocus on a Contact header I know I am in >>>>>>>>> a conference, and that I can subscribe to the conference event >>>>>>>>> package at the contact URI. If I see isFocus in a Feature-Caps header, what does it mean? >>>>>>>>> What can I do once I know this? >>>>>>>>> >>>>>>>>> Section 5.14 of this draft says: >>>>>>>>> >>>>>>>>> This Feature-capability indicator indicates that the intermediary >>>>>>>>> is a conference server, also known as a focus, and is capable of >>>>>>>>> mixing together the media for all calls to the same URI. >>>>>>>>> ... >>>>>>>>> Examples of typical use: A conference bridge >>>>>>>>> indicating that it >>>>>>>>> is a conference bridge and is capable of acting >>>>>>>>> as a conference >>>>>>>>> focus for this session. >>>>>>>>> >>>>>>>>> [AA] the presence of isfocus in a Feature-Caps header field >>>>>>>>> means that a UA can initiate a conference by sending a REFER >>>>>>>>> request to the intermediary to invite another user and create a >>>>>>>>> multi user conference from the 1-1 session. >>>>>>>>> >>>>>>>>> Note that Feature-Caps doesn't indicate which entity has this >>>>>>>>> capability, only that something does. And since this would >>>>>>>>> presumably only be used if it wasn't the UAC of the request, >>>>>>>>> sending a subscribe to the contact address of the UAC wouldn't make sense. >>>>>>>>> >>>>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I >>>>>>>>> consider this application specific and so this would be >>>>>>>>> included in a feature tag registered in the global tree as >>>>>>>>> stated in the draft "RFC 6809 [1] provides that addresses of >>>>>>>>> intermediaries can be communicated as a value of an associated >>>>>>>>> feature-capability indicator so it would be appropriate to >>>>>>>>> define feature capability indicators as part of the global tree >>>>>>>>> to communicate the GRUU of the intermediary and hence this is >>>>>>>>> outside the scope of this document." - RFC 6809 states " If >>>>>>>>> additional data about a supported feature needs to be conveyed, >>>>>>>>> such as the address of the SIP entity that indicated support of >>>>>>>>> the feature, then the feature definition needs to define a way >>>>>>>>> to convey that information as a value of the associated >>>>>>>>> feature-capability indicator." However I think the SIP specific >>>>>>>>> capability indicators such as methods, extensions and events >>>>>>>>> should appropriately be registered in the SIP tree not as >>>>>>>>> proprietary indicator >>>>>>>> s in the global tree. >>>>>>>> >>>>>>>> So you have defined a sip tree feature tag that is only useful >>>>>>>> in conjunction with another feature tag from the global tree. >>>>>>>> And the description of this feature tag doesn't even mention that. >>>>>>>> >>>>>>>> And this all implies a completely non-standard call model - >>>>>>>> doing conferencing in a way inconsistent with RFC 4579. >>>>>>>> >>>>>>>> ISTM that if 4579 doesn't work for you then you should be back >>>>>>>> proposing extensions/revisions to it. >>>>>>>> >>>>>>>>> If there is a conference bridge in the signaling path, then I >>>>>>>>> would expect it to be the UAC. >>>>>>>>> >>>>>>>>> [AA] Although a "standard" way to invoke a conference is to >>>>>>>>> send a REFER to the other UAs to invite them to the conference >>>>>>>>> focus, in many deployments a scenario exists where a call >>>>>>>>> involves an IP-PBX or Telephony Application Server (TAS) that >>>>>>>>> can act as a focus for the conference. A participant of a call >>>>>>>>> can then create a conference by sending a REFER request in >>>>>>>>> dialog to the IP-PBX or TAS to use 3PCC to Invite other users to a conference. Reasons for this are 1. >>>>>>>>> Not all UAs support REFER, >>>>>>>> >>>>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), >>>>>>>> but it *could become* a focus. >>>>>>>> >>>>>>>> The concept that a dialog may contain intermediaries that can be >>>>>>>> addressed to do stuff is not part of any sip standard that I am >>>>>>>> aware of. I don't care too much as long as the "stuff" is >>>>>>>> application stuff that is outside the scope of sip. But when it >>>>>>>> is alternative ways to do stuff that sip supports, then I get upset. >>>>>>>> >>>>>>>>> 2. Many SBCs reject REFER requests going outside domains >>>>>>>>> because of the potential for charging fraud (referring to a >>>>>>>>> premium rate number >>>>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to >>>>>>>>> join the conference may be charged for initiating the call >>>>>>>>> when the scenario is that the initiator of the conference should be charged. >>>>>>>>> 4. No need to obtain and distribute conference URIs. >>>>>>>>> Problem is how to achieve the same behavior without dialog >>>>>>>>> reuse which has been deprecated by RFC 6665? >>>>>>>> >>>>>>>> Then maybe the problem needs to be brought up, and a standard >>>>>>>> solution proposed, rather than simply enabling a proprietary mechanism. >>>>>>>> >>>>>>>>> As another example, consider section 5.1: >>>>>>>>> >>>>>>>>> Descrition: >>>>>>>>> This Feature-capability indicator indicates that the intermediary >>>>>>>>> supports audio as a streaming media type. >>>>>>>>> ... >>>>>>>>> Examples of typical use: An IP PBX indicating that it is >>>>>>>>> capable of accepting and initiating sessions with audio as a >>>>>>>>> streaming media type. >>>>>>>>> >>>>>>>>> This definition *implies* an assumption about the working >>>>>>>>> environment >>>>>>>>> - one that AFAIK is new. It implies that you need to know that >>>>>>>>> intermediaries support a media type before you can use it. >>>>>>>>> Would it be bad if there were no intermediaries, and so none indicated this? >>>>>>>>> What if some intermediary *did* indicate support, but some >>>>>>>>> other doesn't, but doesn't indicate that it doesn't? >>>>>>>>> >>>>>>>>> Bottom line: how would the presence or absence of this feature >>>>>>>>> tag affect subsequent usage? >>>>>>>>> >>>>>>>>> [AA] The absence of the streaming types does not indicate that >>>>>>>>> the intermediary does not support the media type and SDP offer >>>>>>>>> answer will ultimately determine what can or cannot be used if >>>>>>>>> another session is initiated involving the intermediary. >>>>>>>>> However the presence of the media type in a Feature-caps header >>>>>>>>> field does explictly confirm that the intermediary does support >>>>>>>>> the media type and in the scenario where a UA has a choice of >>>>>>>>> multiple intermediaries it could use for a conference it might >>>>>>>>> choose to use the one that explicitly indicates it supports the media types the UA wants to use. >>>>>>>> >>>>>>>> So the UA will be able to discover that *some* intermediary >>>>>>>> supports media it is interested in. And it can tell that *some* >>>>>>>> intermediary says it is a focus. It doesn't know if they are the same intermediary. >>>>>>>> >>>>>>>> And then via some other feature tag it obtains the URI of *some* >>>>>>>> intermediary on the signaling path. Or maybe it gets more than >>>>>>>> one of these. >>>>>>>> >>>>>>>> It then makes a leap of faith and conflates all those things, to >>>>>>>> determine that the URI identifies a focus that supports this media type. >>>>>>>> >>>>>>>> Even then, exactly what does that mean? It may or may not mean >>>>>>>> that it supports mixing that media type in a conference. >>>>>>>> >>>>>>>>> As I stated already I don't care that much about these >>>>>>>>> streaming media types. >>>>>>>> >>>>>>>>> I could go on, but this is enough for now. >>>>>>>>> >>>>>>>>> [AA] My motivation for this is that currently 3GPP are updating >>>>>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>>>>> >>>>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with >>>>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather >>>>>>>>> than forwarding it all the way to the remote UA. >>>>>>>> >>>>>>>> And 6665 deprecates dial reuse in most of those cases. >>>>>>>> Without dialog reuse, the intermediaries don't get an >>>>>>>> opportunity to intercept those. >>>>>>>> >>>>>>>>> In order to know that an intermediary supports the target >>>>>>>>> dialog mechanism needed for a REFER request sent outside the >>>>>>>>> dialog to work we need sip.extensions as a feature-capability >>>>>>>>> indicator. In order to know that the needed event package is >>>>>>>>> supported by the intermediary so we can SUBSCROBE outside the >>>>>>>>> dialog to an intermediary we need sip.events as a feature-capability indicator. >>>>>>>> >>>>>>>> Then I think you should be back here with a problem statement >>>>>>>> and a request for how to get sip to solve it. >>>>>>>> >>>>>>>> And you should touch base with Christer on this. He may have a >>>>>>>> different opinion on the relevance of feature-caps as a solution. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>>>>> >>>>>>>>>> I have submitted a new draft to sipcore to register a number >>>>>>>>>> of feature capability indicators in the SIP tree (based upon >>>>>>>>>> some of the existing SIP media feature tags). The draft can be found at: >>>>>>>>>> >>>>>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00. >>>>>>>>>> txt >>>>>>>>>> >>>>>>>>>> Since there will not be a sipcore session at IETF#88 can we >>>>>>>>>> have an offline discussion on how to progress this draft >>>>>>>>>> (which hopefully is fairly straightforward as it just >>>>>>>>>> registers feature capabilities indicators with IANA). I >>>>>>>>>> wouldn't want to have to wait until March next year for a decision on progressing this. >>>>>>>>>> >>>>>>>>>> Andrew >>>>>>>>>> >>>>>>>>>> -------------------------------------------------------------- >>>>>>>>>> ----- >>>>>>>>>> - >>>>>>>>>> - This transmission (including any attachments) may contain >>>>>>>>>> confidential information, privileged material (including >>>>>>>>>> material protected by the solicitor-client or other applicable >>>>>>>>>> privileges), or constitute non-public information. Any use of >>>>>>>>>> this information by anyone other than the intended recipient >>>>>>>>>> is prohibited. If you have received this transmission in >>>>>>>>>> error, please immediately reply to the sender and delete this >>>>>>>>>> information from your system. Use, dissemination, >>>>>>>>>> distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>>>>>>> >>>>>>>>> --------------------------------------------------------------- >>>>>>>>> ----- >>>>>>>>> - This transmission (including any attachments) may contain >>>>>>>>> confidential information, privileged material (including >>>>>>>>> material protected by the solicitor-client or other applicable >>>>>>>>> privileges), or constitute non-public information. Any use of >>>>>>>>> this information by anyone other than the intended recipient is >>>>>>>>> prohibited. If you have received this transmission in error, >>>>>>>>> please immediately reply to the sender and delete this >>>>>>>>> information from your system. Use, dissemination, distribution, >>>>>>>>> or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> ----------------------------------------------------------------- >>>>>>> ---- This transmission (including any attachments) may contain >>>>>>> confidential information, privileged material (including material >>>>>>> protected by the solicitor-client or other applicable >>>>>>> privileges), or constitute non-public information. Any use of >>>>>>> this informationby anyone other than the intended recipient is >>>>>>> prohibited. If you have >>> received this transmission in error, please immediately reply to the >>> sender and delete this information from your system. Use, >>> dissemination, distribution, or reproduction of this transmission by >>> unintended recipients is not authorized and may be unlawful. >>>>>>> >>>>>>> >>>>>> >>>>>> ------------------------------------------------------------------ >>>>>> --- This transmission (including any attachments) may contain >>>>>> confidential information, privileged material (including material >>>>>> protected by the solicitor-client or other applicable privileges), >>>>>> or constitute non-public information. Any use of this >>>>>> informationby anyone other than the intended recipient is >>>>>> prohibited. If you have >>> received this transmission in error, please immediately reply to the >>> sender and delete this information from your system. Use, >>> dissemination, distribution, or reproduction of this transmission by >>> unintended recipients is not authorized and may be unlawful. >>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> -- This transmission (including any attachments) may contain >>>>> confidential information, privileged material (including material >>>>> protected by the solicitor-client or other applicable privileges), >>>>> or constitute non-public information. Any use of this informationby >>>>> anyone other than the intended recipient is prohibited. If you have >>> received this transmission in error, please immediately reply to the >>> sender and delete this information from your system. Use, >>> dissemination, distribution, or reproduction of this transmission by >>> unintended recipients is not authorized and may be unlawful. >>>>> >>>>> >>>> >>>> -------------------------------------------------------------------- >>>> - This transmission (including any attachments) may contain >>>> confidential information, privileged material (including material >>>> protected by the solicitor-client or other applicable privileges), >>>> or constitute non-public information. Any use of this informationby >>>> anyone other than the intended recipient is prohibited. If you have >>> received this transmission in error, please immediately reply to the >>> sender and delete this information from your system. Use, >>> dissemination, distribution, or reproduction of this transmission by >>> unintended recipients is not authorized and may be unlawful. >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain >>> confidential information, privileged material (including material >>> protected by the solicitor-client or other applicable privileges), or >>> constitute non-public information. Any use of this information by >>> anyone other than the intended recipient is prohibited. If you have >>> received this transmission in error, please immediately reply to the >>> sender and delete this information from your system. Use, >>> dissemination, distribution, or reproduction of this transmission by >>> unintended recipients is not authorized and may be unlawful. >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain >>> confidential information, privileged material (including material >>> protected by the solicitor-client or other applicable privileges), or >>> constitute non-public information. Any use of this information by >>> anyone other than the intended recipient is prohibited. If you have >>> received this transmission in error, please immediately reply to the >>> sender and delete this information from your system. Use, >>> dissemination, distribution, or reproduction of this transmission by >>> unintended recipients is not authorized and may be unlawful. >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > > From pkyzivat@alum.mit.edu Fri Oct 25 13:52:12 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9110B11E821B for ; Fri, 25 Oct 2013 13:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+pclX48dOsJ for ; Fri, 25 Oct 2013 13:52:06 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 8837011E81ED for ; Fri, 25 Oct 2013 13:52:02 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta01.westchester.pa.mail.comcast.net with comcast id hPdL1m0020xGWP851Ys2NS; Fri, 25 Oct 2013 20:52:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id hYs11m00l3ZTu2S3YYs1Xx; Fri, 25 Oct 2013 20:52:02 +0000 Message-ID: <526AD9F1.2070305@alum.mit.edu> Date: Fri, 25 Oct 2013 16:52:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" References: <5266E8EE.5060609@nostrum.com> <4F379740-43E9-4AF0-B80A-CA769F3B94C0@edvina.net>, <52682EB8.2030502@alum.mit.edu> <7C27864E-E549-44EE-B4DF-2A7263FA4530@cisco.com> In-Reply-To: <7C27864E-E549-44EE-B4DF-2A7263FA4530@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382734322; bh=sasGkEf4OwlV+zQz3aenWmzVQwTj7GngGRwipwFFwH8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tSj+C3S9P11NloGkNB0tbn2wUX/IlQv1wgjoVExgqRC7flOcBVodNWRz0NJyo+UXg 35PrrlPrPqy61OaHvB5dliQGwOW60J4shHFKD7J5vqnaVSbqcLUPesm1fmCjj2TyF6 4tD4B/7F8atPxE6p+LIwD7QUEk6JxWerW80jBGFdlEygpAd1dB/19d+PiwNTJobhZV aQXlVnOs4S4VLw7kwRgIEVTs/Sx6vpkKVTHBng1mcjGvDz60Os17BtWkmaRtBW1h6m 1IXwzTeG+C3xHwDbkgIzuWHQqSdz0ZCX+XLE0esNxVtQGhc5k+TCp9vbuANcIISTlR CFld+meCzxGqg== Cc: "sipcore@ietf.org" , "ipv6@sipforum.org" Subject: Re: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:52:12 -0000 On 10/25/13 1:50 PM, Gonzalo Salgueiro (gsalguei) wrote: > >> On Oct 23, 2013, at 4:17 PM, "Paul Kyzivat" wrote: >> >>> On 10/23/13 3:36 PM, Olle E. Johansson wrote: >>> >>> Personally I think it's the duty of the IETF to make sure that the transition to IPv6 works smoothly. Without work on dual stack, the SIP vendors will not dare delivering dual stack solutions and we'll stay on IPv4-only VPNs. >>> We have proven that there are a lot of issues with dual stack networks at SIPit tests. >> >> I think so too. >> But the only resources the IETF has to work on this are the ones reading this mail. What we need to know is if there is a sufficient body of people willing, and sufficiently knowledgeable, to *contribute*. Minimally by reviewing and commenting on drafts. But we need people who will do more - provide text, implement, test. > > I should point out that this deficiency was initially uncovered through interop and performance testing done by the SIP Forum (SIPit) and then subsequently taken on as a work item by the SIP Forum IPv6 TG (copied here). So, in addition to those who have offered their support and willingness to contribute over the past few weeks, there are other interested (and qualified) folks that could contribute to reviews, implement, test, etc. Hopefully they will step up here and volunteer. Thanks, Paul From christer.holmberg@ericsson.com Fri Oct 25 13:55:20 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C55411E8203 for ; Fri, 25 Oct 2013 13:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.866 X-Spam-Level: X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=-2.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BY8lzwpRaLsh for ; Fri, 25 Oct 2013 13:55:12 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2368611E8179 for ; Fri, 25 Oct 2013 13:55:10 -0700 (PDT) X-AuditID: c1b4fb38-b7f178e00000233b-0b-526adaaada52 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E2.52.09019.AAADA625; Fri, 25 Oct 2013 22:55:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Fri, 25 Oct 2013 22:55:06 +0200 From: Christer Holmberg To: Andrew Allen , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cIzpzAuA9v06UeMMLOm99XPQZoF459sgAAB1a0= Date: Fri, 25 Oct 2013 20:55:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F7363@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4F7363ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+Jvje7qW1lBBm17OSzuz9vKaLFiwwFW i68/NrE5MHv8ff+ByWNWw1p2jyVLfjIFMEdx2aSk5mSWpRbp2yVwZaw6cY61YO8Otorf/7qY Gxif7WPtYuTkkBAwkbh0/R6ULSZx4d56ti5GLg4hgaOMEo09DxkhnCWMEs3TzgBVcXCwCVhI dP/TBmkQESiXeHzyMBuILSyQKPHqygxmiHiSxM0N9xghbCuJSRc+s4DYLAKqEjdvrgazeQV8 JU6vPsQOMX86s8SD7TfAruAU8JSY//wLWBEj0EXfT61hArGZBcQlbj2ZzwRxqYDEkj3nmSFs UYmXj/9BfaAk8WPDJRaI+nyJs1PvM0MsE5Q4OfMJywRGkVlIRs1CUjYLSRlEXE/ixtQpbBC2 tsSyha+ZIWxdiRn/DkHVWEu8fnuBGVnNAkaOVYwcxanFSbnpRgabGIHxdnDLb4sdjJf/2hxi lOZgURLn/fjWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo2jETdV6cd7VyV82qPZaPkir 66+0bN4lOu3Jtzt6adfWx/2daxrKM/eDwqmimZ1zqyVUfr78f+F+xemP9wtXii6uFSnzPrT/ TYyFQJFa2/NQh5g/jEkv5r3bNjMt2n+v0TEuTzHNf+ETt4pqmUnN8z4Vtuv1KXHuD45Jizq6 irQbG1ZZmr8xUWIpzkg01GIuKk4EAGePqxiFAgAA Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:55:20 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4F7363ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >In my view the basic premise of Feature-Caps is that an entity on the rout= e is indicating that it supports a particular capability. Indicating suppor= t for features > by other entities is rather problematic. I suppose a service proxy on the= route could also indicate features supported by other physical servers tha= t it has > responsibility for that are not hosted physically by it. > > I agree with Christer that if an entity needs to support multiple sets of= features that do not all apply to the same server then it should do so in = separate > Feature-Caps header fields with only the features that are all hosted by = the same entity being included in the same Feature-Caps header field. > > I think entities advertising features that they are not responsible for a= nd have nothing to do with is bogus. It depends on what you mean by "responsible for". Even if the feature logic= is not executed by the same physical entity that handles the SIP signaling= , the SIP signaling entity can still be "responsible", e.g. if "responsible= " means dispatching and distributing functions which will execute features. Having said that, in most cases I assume that the entity indicating support= of a feature actually IS the same entity that also executes the feature, b= ut it is nowhere mandated to be that way. Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: Friday, October 25, 2013 4:28 PM To: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators Inline. On 10/25/13 2:57 PM, Christer Holmberg wrote: > Hi, > > .... > >>> /Example:/ >>> >>> I support the find-Paul feature, and I insert a FCI: >>> >>> Feature-Caps: *, +g.find-paul=3D"sip:pkyzivat@alum.mit.edu" >>> >>> Now, in this case the address does NOT point to my entity, but to >>> Paul's entity. My entity supports a feature, which provides Paul's addr= ess. >>> >>> So, if the FCI says: >>> >>> Feature-Caps: *, >>> +g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.methods=3D"invite" >>> >>> ...it doesn't automatically mean that I can contact Paul using INVITE. >>> By default it means that MY entity supports the INVITE method - >>> which from the find-paul feature perspective is useless information. >>> >>> So, in the FCI specification for +g.find-paul, I would have to >>> explictily describe how the FCI works in conjunction with other >>> FCIs. I would have to explicitly say that, when used together >>> +sip.methods, the >>> +sip.methods indicates which SIP methods I can use to contact Paul >>> (using the address provide in the +g.find-paul FCI). >> >> So far I agree. >> >> But suppose there is also a find-christer FCI. So we have: >> >> Feature-Caps: * >> ;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu" >> ;+g.find-paul=3D"sip:christer.holmberg@ericsson.com" >> ;+sip.methods=3D"invite" >> >> And both find-paul and find-christer want to define the use of other >> FCIs. Then things start to become ambiguous. >> >> Should the description of find-paul specify what other FCIs "pertain" >> to it? Or should the description of sip.methods specify what FCI(s) >> provide the address at which it applies? Or both? What if paul and >> christer support different methods? > > In that case you would need to have two different Feature-Caps header > fields: > > Feature-Caps: > *;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.methods=3D"invite" > Feature-Caps: > *;+g.find-paul=3D"sip:christer.holmberg@ericsson.com";+sip.methods=3D"mes= sage" That seemingly solves the problem, but if the same entity inserts them both= then its a questionable use of Feature-caps isn't it? > In your example you had two instances of the same FCI (is that even > allowed?), I did? find-paul and find-christer are two different FCIs. (But that sort of naming will be troublesome for the registry and for the e= xpert who has to approve entries in it.:-) but there could also have been a case with two different > FCIs, both using +sip.methods, in which case you may have to put them > into separate Feature-Caps header fields. > > These things would have to be clearly specified. Very definitely. Thanks, Paul > Regards, > > Christer > > >> Section 5.3.8 in RFC 6809 also says: >> >> "If there is additional information about the feature-capability >> indicator, it is recommended to describe such information. It c= an >> include, for example, *names of related feature-capability >> indicators*." >> >> So, in your case, I think the +g.3gpp.see_trans FCI specifiction >> would have to specify how the FCI is used in conjuntion with other >> FCIs, including the +sip.method FCI. >> >> Something like: "When the session transfer request is sent to the >> address indicated by the FCI value, the +sip.method FCI indicates >> which SIP methods can be used." >> >> Regards, >> >> Christer >> >> >> >> *From*: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> *Sent*: Friday, October 25, 2013 12:01 PM Central Standard Time >> *To*: Andrew Allen; Paul Kyzivat ; Gonzalo >> Camarillo >> *Cc*: rlb@ipv.sx ; adam@nostrum.com ; >> mary.ietf.barnes@gmail.com >> *Subject*: RE: New sipcore draft submission >> draft-allen-sipcore-sip-tree-cap-indicators >> >> Hi, >> >>>I think we can have an FCI >> >>> >> >>>Feature-Caps: *;+g.3ggp.sess_trans=3D"sip:foo@example.com;gr" >> >>> >> >>>Indicating that the entity supports 3GPP session transfer and the >>>address where you send the session transfer request is >>>sip:foo@example.com;gr >> >> Correct. The FCI itself indicates support of session transfer >> feature, and the FCI value indicates the address associatd with the feat= ure. >> >>>Also if I have: >> >>> >> >>>Feature-Caps: *;+g.3ggp.sess_trans=3Dsip:foo@example.com;gr; >>>+sip.extensions=3D"replaces, tdialog"; >> +sip.methods=3D"invite, refer, bye, options, update, prack" >> >>> >> >>> This means the entity supports 3GPP session transfer and the address wh= ere you send the session transfer request is sip:foo@example.com;gr ... >> >> Correct. >> >>> ...supports the replaces and target dialog extensions and supports the = following methods - invite, refer, bye, options, update, prack. >> >> Technically, what it means is that there is *AN* entity which >> supports the features listed above, and the address is where you are >> to send the session transfer request in order to trigger the 3GPP >> session transfer feature. >> >> Regards, >> >> Christer >> >> *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> *Sent:* Friday, October 25, 2013 10:25 AM >> *To:* Paul Kyzivat; Andrew Allen; Gonzalo Camarillo >> *Cc:* rlb@ipv.sx; adam@nostrum.com; mary.ietf.barnes@gmail.com >> *Subject:* RE: New sipcore draft submission >> draft-allen-sipcore-sip-tree-cap-indicators >> >> Hi, >> >> As Paul said, if one needs to provide address information associated >> with a FCI, the address information cannot be a FCI of its own. It >> needs to be a value of the FCI for which it is associated. >> >> Something like: >> >> Feature-Caps: *;+audio=3D"sip:foo@example.com" >> >> (Also note that the "+" sign is mandatory for all FCIs - no matter >> which registry tree they belong to) >> >> Regards, >> >> Christer >> >> --------------------------------------------------------------------- >> --- >> >> *From:*Paul Kyzivat [pkyzivat@alum.mit.edu] >> *Sent:* Friday, 25 October 2013 5:06 PM >> *To:* Andrew Allen; Gonzalo Camarillo >> *Cc:* rlb@ipv.sx ; adam@nostrum.com >> ; Christer Holmberg; >> mary.ietf.barnes@gmail.com >> *Subject:* Re: New sipcore draft submission >> draft-allen-sipcore-sip-tree-cap-indicators >> >> Andrew, >> >> (I see this is still on the private thread. I'll reply here, but this >> exchange should probably be reposted to the sipcore list as part of >> the public discussion of the draft.) >> >> On 10/24/13 10:41 PM, Andrew Allen wrote: >>> >>> Paul >>> >>> I am happy to do a revision with more details on the semantics of the c= apability indicators. However I don't think it should be held to a very muc= h higher bar than the details in RFC 3840 and the other media feature tag R= FCs regarding the meaning of thosetags. >> >> Keep in mind that the driving force for the definition of feature >> tags in 3840 was in support of callerprefs (3841). So the context for >> the use of feature tags was that they would be placed on Contacts in >> REGISTER requests. So you can interpret the definitions in that >> context: that a request sent to an AOR using callerprefs can affect >> the choice of which device the request goes to according to the >> capabilities it wants. In that context audio, video, isfocus all make se= nse. >> >> Their use on Contacts in dialogs was derivative to that: because >> callerpref support is optional, there is no guarantee that the device >> you reach via callerprefs will have the capabilities you requested. >> So the values in the contact help confirm what you got. >> >> Of course they have since been used other ways. And the descriptions >> of them don't necessarily reflect that. IMO that is a defect due to >> the evolution of use. >> >> I'm looking for the same sort of context for use with the feature-caps. >> >> In private discussion you indicated to me that you expected the >> feature caps to be grouped - with one of them giving the URI of the >> device that the other tags apply to. I guess this would end up looking s= omething like: >> >> Feature-Caps: *;g.uri=3D"sip:foo@example.com";audio >> Feature-Caps: *;g.uri=3D"sip:bar@example.com";audio;video;isfocus >> Feature-Caps: *;g.uri=3D"sip:baz@example.com";text >> >> (I'm making up g.uri for the example.) >> >> And then presumably somebody on the signaling path will "shop" in the >> feature caps for the capabilities it wants, and then send a request >> to that URI, with the expectation that the UA responding will have >> those capabilities. >> >>> The semantics should be no different than those of the corresponding e= xisting media feature tag if it is present in the Contact header. >> >> Note that 6809 says: >> >> When a SIP entity receives a SIP request, or response, that contain= s >> one or more Feature-Caps header fields, the feature-capability >> indicators in the header field inform the entity about the features >> and capabilities supported by entities in the SIP message signaling >> path. The procedure by which features and capabilities are invoked >> are outside the scope of this specification and MUST be described b= y >> individual feature-capability indicator specifications. >> >> A Feature-Caps header field value cannot convey the address of the >> SIP entity that inserted the Feature-Caps header field. If >> additional data about a supported feature needs to be conveyed, suc= h >> as the address of the SIP entity that indicated support of the >> feature, then the feature definition needs to define a way to conve= y >> that information as a value of the associated feature-capability >> indicator. >> >> This was discussed at length while that RFC was under consideration. >> Yet the definitions of the tags in *this* draft don't specify that. >> >>> The registration templates currently reference the RFC 3840 and the oth= er RFCs that define the other media feature tags that correspond to these f= eature capability indicators. >> >> And those definitions were written to be understood in the context of >> 3840/3841. They make sense in that context, but not in *this* context. >> >> Thanks, >> Paul >> >>> But if more explicit detail is required then I can add some more text = or alternatively remove the less important ones if they are going to become= rat holes. The ones I regard as really important and urgent are sip.method= s, sip.extensions and sip.events the meaning of which I think should be q= uite clear. >>> >>> Andrew >>> >>> ----- Original Message ----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >>> To: Andrew Allen;Gonzalo.Camarillo@ericsson.com >>> >> > > >>> Cc:rlb@ipv.sx >; >> adam@nostrum.com > >; christer.holmberg@ericsson.com >> >> > >; mary.ietf.barnes@gmail.com >> > >; Paul Kyzivat >> > >>> Subject: Re: New sipcore draft submission >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> On 10/24/13 4:07 PM, Andrew Allen wrote: >>>> >>>> Paul >>>> >>>> Ok >>>> >>>> So we are basically where I thought we were at when I submitted the dr= aft. >>>> >>>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else wh= o indicates interest) can have some offline discussion in Vancouver on whet= her and how to progress this. >>> >>> As I indicated again on the sipcore list, I found the that the draft >>> didn't explain nearly enough to allow meaningful use of these. >>> I know you replied, and I will continue the conversation there. >>> But I will be opposed to these until and unless the draft (and >>> notably the descriptions of the tags) are clear about how one could >>> figure out what can do in the presence of the tags that one couldn't >>> do without them. AND, that the behavior that suggests doesn't >>> "break" sip. (E.g., by advocating a new and incompatible way to do >>> something.) >>> >>> We can continue this on the sipcore list. >>> >>> Thanks, >>> Paul >>> >>>> Andrew >>>> >>>> ----- Original Message ----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >>>> To: Andrew Allen; Gonzalo Camarillo >>> > >>>> Cc: Richard Barnes (rlb@ipv.sx ) >>> >; Adam >> Roach (adam@nostrum.com ) > >; Christer Holmberg >> (christer.holmberg@ericsson.com >> ) >> > >; Mary Barnes >> (mary.ietf.barnes@gmail.com ) < >> mary.ietf.barnes@gmail.com > >>>> Subject: Re: New sipcore draft submission >>>> draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> On 10/24/13 2:17 PM, Andrew Allen wrote: >>>>> Paul >>>>> >>>>> That is fine. Although Mary in her reply to me seemed to indicate may= be there was a possibility to use some of the DISPATCH spare time for a SIP= CORE session for this. Is that a possibility? >>>>> >>>>> I already replied to your post >>>> >>>> I discussed that with Adam. We decided we can't set a precedent to >>>> spin up a session to discuss a draft that hasn't had substantial >>>> (any) list discussion. >>>> >>>> But list discussion is always welcome. >>>> >>>> Sorry, >>>> Paul >>>> >>>>> Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Sent: Thursday, October 24, 2013 1:31 PM >>>>> To: Andrew Allen; Gonzalo Camarillo >>>>> Cc: Richard Barnes (rlb@ipv.sx ); Adam Roach >>>>> (adam@nostrum.com >> ); Christer Holmberg >> (christer.holmberg@ericsson.com >> ) >>>>> Subject: Re: New sipcore draft submission >>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>> >>>>> Andrew, >>>>> >>>>> I spoke with Mary about it, and we concluded that dispatch isn't righ= t for this. (In addition to being clearly sipcore, it didn't meet the deadl= ine for dispatch.) I was wrong to encourage you that way. >>>>> >>>>> So no official live discussion in Vancouver. (But informal >>>>> discussion >>>>> fine.) >>>>> >>>>> I'll resend my private comments to the sipcore list to kickstart some= discussion there. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>>>> I just emailed Mary asking for agenda time. Should I cancel that req= uest? >>>>>> >>>>>> -----Original Message----- >>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>>> Sent: Thursday, October 24, 2013 1:00 PM >>>>>> To: Paul Kyzivat >>>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx >>>>>> ); Adam Roach (adam@nostrum.com >>>>>> ); Christer Holmberg >> (christer.holmberg@ericsson.com >> ) >>>>>> Subject: Re: New sipcore draft submission >>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>> >>>>>> Hi Paul, >>>>>> >>>>>> given that you think this belongs to SIPCORE, I do not see the need = to run it through DISPATCH. Please, start technical discussions on the draf= t on the SIPCORE list. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>>>> Paul >>>>>>>> >>>>>>>> Thanks for reviewing the draft already and giving me early feedbac= k. >>>>>>>> >>>>>>>> My responses below inline (prepended with [AA). >>>>>>>> >>>>>>>> Can I ask the ADs to determine ASAP if this needs to go to >>>>>>>> DISPATCH first or not. As outlined below my view is that it is >>>>>>>> unnecessary for every little thing to go to DISPATCH as this >>>>>>>> just creates additional delay and overhead. If it is to be >>>>>>>> discussed in DISPATCH then I definitely would want agenda time atI= ETF#88 for this. >>>>>>> >>>>>>> Having now seen Andrew's responses to my initial questions, I >>>>>>> think this >>>>>>> *needs* to be carefully considered by sipcore. IMO this has the >>>>>>> potential to create a dialect of sip that is incompatible with >>>>>>> normal usage. (Maybe IMS has already done that. But this will >>>>>>> make it >>>>>>> worse.) >>>>>>> >>>>>>> But if there is a desire to discuss it publicly in Vancouver >>>>>>> then dispatch is the opportunity and so some discussion on the >>>>>>> dispatch list in advance of that would be appropriate. >>>>>>> >>>>>>> I'll defer to the ADs on this. >>>>>>> >>>>>>> More inline. >>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx >>>>>>>> ); Gonzalo Camarillo >>>>>>>> (Gonzalo.Camarillo@ericsson.com >>>>>>>> ); >> Adam Roach (adam@nostrum.com ) >>>>>>>> Subject: Re: New sipcore draft submission >>>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>>> >>>>>>>> Andrew, >>>>>>>> >>>>>>>> On a legalistic note, its questionable to me whether this kind >>>>>>>> of action falls within the scope of sipcore. OTOH, among >>>>>>>> existing wgs, sipcore is probably the best suited to discuss >>>>>>>> the proposal. We could take it to DISPATCH. I think DISPATCH >>>>>>>> has extra time in its agenda for Vancouver, so that might be >>>>>>>> one option for you. But then I don't know where dispatch would >>>>>>>> dispatch it. It may be that AD sponsored is the best way to go. >>>>>>>> >>>>>>>> [AA] It seemed to me that sipcore was the right place. This >>>>>>>> draft registers feature-capability indicators in a registry >>>>>>>> that was created by a sipcore RFC (RFC 6809). You could in my >>>>>>>> view make an argument that this should even have been done as part= of RFC 6809. >>>>>>> >>>>>>> If this was just a matter of registering some new feature caps >>>>>>> that were not controversial, then I don't think sipcore needs to be= involved. >>>>>>> >>>>>>> But as I mentioned above, I do consider these controversial. >>>>>>> >>>>>>>> Discussing it now on the dispatch list would be a good start >>>>>>>> toward discussing it at the dispatch session. >>>>>>>> >>>>>>>> [AA] Can I ask the ADs to determine if this needs to go to >>>>>>>> DISPATCH first or not. My view is that it is unnecessary for >>>>>>>> every little thing to go to DISPATCH as this just creates addition= al delay and overhead. >>>>>>>> This just registers some indicators in an existing IANA >>>>>>>> registry and is not (or should not be IMHO) a major project. >>>>>>> >>>>>>> To me this is a matter of whether you want to be opportunistic. >>>>>>> If this went to dispatch I would now recommend that it be >>>>>>> dispatched to sipcore. So its a matter of whether you want to >>>>>>> talk about it in the dispatch meeting. >>>>>>> >>>>>>>> Regarding substance, this draft troubles me. It takes >>>>>>>> feature-caps in exactly the direction that I found most >>>>>>>> concerning about the mechanism in the first place. >>>>>>>> >>>>>>>> Your draft partitions the existing media feature tags into two >>>>>>>> sets >>>>>>>> - those that would be useful as feature-capability-indicators, >>>>>>>> and those that aren't. But I see no explanation of the criteria >>>>>>>> used to make this distinction, nor can I think of one. >>>>>>>> >>>>>>>> [AA] I based this decision on the following criteria: If a >>>>>>>> feature tag was potentially at all useful for an intermediary >>>>>>>> to indicate it then include it in the registry. The ones not >>>>>>>> included are either directly associated with the user >>>>>>>> (intermediaries are not directly associated with the user) or >>>>>>>> would only ever have one value (e.g automata). I am not sure >>>>>>>> that every feature-capability indicator proposed to be >>>>>>>> registered is actually useful but then I don't think every >>>>>>>> media feature tag registered by RFC 3840 is either (I doubt >>>>>>>> very much if there are implementation using the sip.application >>>>>>>> or sip.control feature tags). I don't think RFC 3840 goes into >>>>>>>> a lot of details justifying of ever registered media feature >>>>>>>> tag and specifying the details of how they would be used >>>>>>>> either. I am willing to remove any feature-capability indicators = that are controversial except that I think we definitely need sip.extension= s, sip.methods and sip.events. >>>>>>>> There is a significant overhead to writing an >>>>>>> d progressing internet drafts so my view is lets register all >>>>>>> that might be remotely useful in the same document. >>>>>>> >>>>>>> The judgement of "useful" is reasonable. But I still can't >>>>>>> discern what the use is from the iana registration descriptions. >>>>>>> >>>>>>>> For the ones that you have requested feature capability >>>>>>>> indicators, I cannot figure out what using them would mean. For >>>>>>>> example, when I see isFocus on a Contact header I know I am in >>>>>>>> a conference, and that I can subscribe to the conference event >>>>>>>> package at the contact URI. If I see isFocus in a Feature-Caps hea= der, what does it mean? >>>>>>>> What can I do once I know this? >>>>>>>> >>>>>>>> Section 5.14 of this draft says: >>>>>>>> >>>>>>>> This Feature-capability indicator indicates that the i= ntermediary >>>>>>>> is a conference server, also known as a focus, and is = capable of >>>>>>>> mixing together the media for all calls to the same UR= I. >>>>>>>> ... >>>>>>>> Examples of typical use: A conference bridge >>>>>>>> indicating that it >>>>>>>> is a conference bridge and is capable of acting >>>>>>>> as a conference >>>>>>>> focus for this session. >>>>>>>> >>>>>>>> [AA] the presence of isfocus in a Feature-Caps header field >>>>>>>> means that a UA can initiate a conference by sending a REFER >>>>>>>> request to the intermediary to invite another user and create a >>>>>>>> multi user conference from the 1-1 session. >>>>>>>> >>>>>>>> Note that Feature-Caps doesn't indicate which entity has this >>>>>>>> capability, only that something does. And since this would >>>>>>>> presumably only be used if it wasn't the UAC of the request, >>>>>>>> sending a subscribe to the contact address of the UAC wouldn't mak= e sense. >>>>>>>> >>>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I >>>>>>>> consider this application specific and so this would be >>>>>>>> included in a feature tag registered in the global tree as >>>>>>>> stated in the draft "RFC 6809 [1] provides that addresses of >>>>>>>> intermediaries can be communicated as a value of an associated >>>>>>>> feature-capability indicator so it would be appropriate to >>>>>>>> define feature capability indicators as part of the global tree >>>>>>>> to communicate the GRUU of the intermediary and hence this is >>>>>>>> outside the scope of this document." - RFC 6809 states " If >>>>>>>> additional data about a supported feature needs to be conveyed, >>>>>>>> such as the address of the SIP entity that indicated support of >>>>>>>> the feature, then the feature definition needs to define a way >>>>>>>> to convey that information as a value of the associated >>>>>>>> feature-capability indicator." However I think the SIP specific >>>>>>>> capability indicators such as methods, extensions and events >>>>>>>> should appropriately be registered in the SIP tree not as >>>>>>>> proprietary indicator >>>>>>> s in the global tree. >>>>>>> >>>>>>> So you have defined a sip tree feature tag that is only useful >>>>>>> in conjunction with another feature tag from the global tree. >>>>>>> And the description of this feature tag doesn't even mention that. >>>>>>> >>>>>>> And this all implies a completely non-standard call model - >>>>>>> doing conferencing in a way inconsistent with RFC 4579. >>>>>>> >>>>>>> ISTM that if 4579 doesn't work for you then you should be back >>>>>>> proposing extensions/revisions to it. >>>>>>> >>>>>>>> If there is a conference bridge in the signaling path, then I >>>>>>>> would expect it to be the UAC. >>>>>>>> >>>>>>>> [AA] Although a "standard" way to invoke a conference is to >>>>>>>> send a REFER to the other UAs to invite them to the conference >>>>>>>> focus, in many deployments a scenario exists where a call >>>>>>>> involves an IP-PBX or Telephony Application Server (TAS) that >>>>>>>> can act as a focus for the conference. A participant of a call >>>>>>>> can then create a conference by sending a REFER request in >>>>>>>> dialog to the IP-PBX or TAS to use 3PCC to Invite other users to a= conference. Reasons for this are 1. >>>>>>>> Not all UAs support REFER, >>>>>>> >>>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), >>>>>>> but it *could become* a focus. >>>>>>> >>>>>>> The concept that a dialog may contain intermediaries that can be >>>>>>> addressed to do stuff is not part of any sip standard that I am >>>>>>> aware of. I don't care too much as long as the "stuff" is >>>>>>> application stuff that is outside the scope of sip. But when it >>>>>>> is alternative ways to do stuff that sip supports, then I get upset= . >>>>>>> >>>>>>>> 2. Many SBCs reject REFER requests going outside domains >>>>>>>> because of the potential for charging fraud (referring to a >>>>>>>> premium rate number >>>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to >>>>>>>> join the conference may be charged for initiating the call >>>>>>>> when the scenario is that the initiator of the conference should b= e charged. >>>>>>>> 4. No need to obtain and distribute conference URIs. >>>>>>>> Problem is how to achieve the same behavior without dialog >>>>>>>> reuse which has been deprecated by RFC 6665? >>>>>>> >>>>>>> Then maybe the problem needs to be brought up, and a standard >>>>>>> solution proposed, rather than simply enabling a proprietary mechan= ism. >>>>>>> >>>>>>>> As another example, consider section 5.1: >>>>>>>> >>>>>>>> Descrition: >>>>>>>> This Feature-capability indicator indicates that the i= ntermediary >>>>>>>> supports audio as a streaming media type. >>>>>>>> ... >>>>>>>> Examples of typical use: An IP PBX indicating that = it is >>>>>>>> capable of accepting and initiating sessions with a= udio as a >>>>>>>> streaming media type. >>>>>>>> >>>>>>>> This definition *implies* an assumption about the working >>>>>>>> environment >>>>>>>> - one that AFAIK is new. It implies that you need to know that >>>>>>>> intermediaries support a media type before you can use it. >>>>>>>> Would it be bad if there were no intermediaries, and so none indic= ated this? >>>>>>>> What if some intermediary *did* indicate support, but some >>>>>>>> other doesn't, but doesn't indicate that it doesn't? >>>>>>>> >>>>>>>> Bottom line: how would the presence or absence of this feature >>>>>>>> tag affect subsequent usage? >>>>>>>> >>>>>>>> [AA] The absence of the streaming types does not indicate that >>>>>>>> the intermediary does not support the media type and SDP offer >>>>>>>> answer will ultimately determine what can or cannot be used if >>>>>>>> another session is initiated involving the intermediary. >>>>>>>> However the presence of the media type in a Feature-caps header >>>>>>>> field does explictly confirm that the intermediary does support >>>>>>>> the media type and in the scenario where a UA has a choice of >>>>>>>> multiple intermediaries it could use for a conference it might >>>>>>>> choose to use the one that explicitly indicates it supports the me= dia types the UA wants to use. >>>>>>> >>>>>>> So the UA will be able to discover that *some* intermediary >>>>>>> supports media it is interested in. And it can tell that *some* >>>>>>> intermediary says it is a focus. It doesn't know if they are the sa= me intermediary. >>>>>>> >>>>>>> And then via some other feature tag it obtains the URI of *some* >>>>>>> intermediary on the signaling path. Or maybe it gets more than >>>>>>> one of these. >>>>>>> >>>>>>> It then makes a leap of faith and conflates all those things, to >>>>>>> determine that the URI identifies a focus that supports this media = type. >>>>>>> >>>>>>> Even then, exactly what does that mean? It may or may not mean >>>>>>> that it supports mixing that media type in a conference. >>>>>>> >>>>>>>> As I stated already I don't care that much about these >>>>>>>> streaming media types. >>>>>>> >>>>>>>> I could go on, but this is enough for now. >>>>>>>> >>>>>>>> [AA] My motivation for this is that currently 3GPP are updating >>>>>>>> their specifications to use RFC 6665 instead of RFC 3265. >>>>>>> >>>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with >>>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather >>>>>>>> than forwarding it all the way to the remote UA. >>>>>>> >>>>>>> And 6665 deprecates dial reuse in most of those cases. >>>>>>> Without dialog reuse, the intermediaries don't get an >>>>>>> opportunity to intercept those. >>>>>>> >>>>>>>> In order to know that an intermediary supports the target >>>>>>>> dialog mechanism needed for a REFER request sent outside the >>>>>>>> dialog to work we need sip.extensions as a feature-capability >>>>>>>> indicator. In order to know that the needed event package is >>>>>>>> supported by the intermediary so we can SUBSCROBE outside the >>>>>>>> dialog to an intermediary we need sip.events as a feature-capabili= ty indicator. >>>>>>> >>>>>>> Then I think you should be back here with a problem statement >>>>>>> and a request for how to get sip to solve it. >>>>>>> >>>>>>> And you should touch base with Christer on this. He may have a >>>>>>> different opinion on the relevance of feature-caps as a solution. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>>>> >>>>>>>>> I have submitted a new draft to sipcore to register a number >>>>>>>>> of feature capability indicators in the SIP tree (based upon >>>>>>>>> some of the existing SIP media feature tags). The draft can be fo= und at: >>>>>>>>> >>>>>>>>>http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicators= -00. >>>>>>>>> txt >>>>>>>>> >>>>>>>>> Since there will not be a sipcore session at IETF#88 can we >>>>>>>>> have an offline discussion on how to progress this draft >>>>>>>>> (which hopefully is fairly straightforward as it just >>>>>>>>> registers feature capabilities indicators with IANA). I >>>>>>>>> wouldn't want to have to wait until March next year for a decisio= n on progressing this. >>>>>>>>> >>>>>>>>> Andrew >>>>>>>>> >>>>>>>>> -------------------------------------------------------------- >>>>>>>>> ----- >>>>>>>>> - >>>>>>>>> - This transmission (including any attachments) may contain >>>>>>>>> confidential information, privileged material (including >>>>>>>>> material protected by the solicitor-client or other applicable >>>>>>>>> privileges), or constitute non-public information. Any use of >>>>>>>>> this information by anyone other than the intended recipient >>>>>>>>> is prohibited. If you have received this transmission in >>>>>>>>> error, please immediately reply to the sender and delete this >>>>>>>>> information from your system. Use, dissemination, >>>>>>>>> distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful. >>>>>>>> >>>>>>>> --------------------------------------------------------------- >>>>>>>> ----- >>>>>>>> - This transmission (including any attachments) may contain >>>>>>>> confidential information, privileged material (including >>>>>>>> material protected by the solicitor-client or other applicable >>>>>>>> privileges), or constitute non-public information. Any use of >>>>>>>> this information by anyone other than the intended recipient is >>>>>>>> prohibited. If you have received this transmission in error, >>>>>>>> please immediately reply to the sender and delete this >>>>>>>> information from your system. Use, dissemination, distribution, >>>>>>>> or reproduction of this transmission by unintended recipients is n= ot authorized and may be unlawful. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> ----------------------------------------------------------------- >>>>>> ---- This transmission (including any attachments) may contain >>>>>> confidential information, privileged material (including material >>>>>> protected by the solicitor-client or other applicable >>>>>> privileges), or constitute non-public information. Any use of >>>>>> this informationby anyone other than the intended recipient is >>>>>> prohibited. If you have >> received this transmission in error, please immediately reply to the >> sender and delete this information from your system. Use, >> dissemination, distribution, or reproduction of this transmission by >> unintended recipients is not authorized and may be unlawful. >>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------ >>>>> --- This transmission (including any attachments) may contain >>>>> confidential information, privileged material (including material >>>>> protected by the solicitor-client or other applicable privileges), >>>>> or constitute non-public information. Any use of this >>>>> informationby anyone other than the intended recipient is >>>>> prohibited. If you have >> received this transmission in error, please immediately reply to the >> sender and delete this information from your system. Use, >> dissemination, distribution, or reproduction of this transmission by >> unintended recipients is not authorized and may be unlawful. >>>>> >>>>> >>>> >>>> ------------------------------------------------------------------- >>>> -- This transmission (including any attachments) may contain >>>> confidential information, privileged material (including material >>>> protected by the solicitor-client or other applicable privileges), >>>> or constitute non-public information. Any use of this informationby >>>> anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the >> sender and delete this information from your system. Use, >> dissemination, distribution, or reproduction of this transmission by >> unintended recipients is not authorized and may be unlawful. >>>> >>>> >>> >>> -------------------------------------------------------------------- >>> - This transmission (including any attachments) may contain >>> confidential information, privileged material (including material >>> protected by the solicitor-client or other applicable privileges), >>> or constitute non-public information. Any use of this informationby >>> anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the >> sender and delete this information from your system. Use, >> dissemination, distribution, or reproduction of this transmission by >> unintended recipients is not authorized and may be unlawful. >>> >>> >> >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain >> confidential information, privileged material (including material >> protected by the solicitor-client or other applicable privileges), or >> constitute non-public information. Any use of this information by >> anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the >> sender and delete this information from your system. Use, >> dissemination, distribution, or reproduction of this transmission by >> unintended recipients is not authorized and may be unlawful. >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain >> confidential information, privileged material (including material >> protected by the solicitor-client or other applicable privileges), or >> constitute non-public information. Any use of this information by >> anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the >> sender and delete this information from your system. Use, >> dissemination, distribution, or reproduction of this transmission by >> unintended recipients is not authorized and may be unlawful. >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_7594FB04B1934943A5C02806D1A2204B1C4F7363ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <90A37B80E31E4D4D802E2A18CFB8A28B@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,


>In my view the basic premise of Feature-Caps is that an entity on the r= oute is indicating that it supports a particular capability. Indicating sup= port for features

> by other entities is rather problematic. I suppose a service proxy = on the route could also indicate features supported by other physical serve= rs that it has

> responsibility for that are not hosted physically by it.
>
> I agree with Christer that if an entity needs to support multiple sets= of features that do not all apply to the same server then it should do so = in separate

> Feature-Caps header fields with only the features that are all host= ed by the same entity being included in the same Feature-Caps header field.=
>
> I think entities advertising features that they are not responsible fo= r and have nothing to do with is bogus.

 

It depends on what you mean by "responsible for". Even if=  the feature logic is not executed by the same physical entity th= at handles the SIP signaling, the SIP signaling entity can still be "r= esponsible", e.g. if "responsible" means dispatching and dis= tributing functions which will execute features.

 

Having said that, in most cases I assume that the entity indicating supp= ort of a feature actually IS the same entity that also execu= tes the feature, but it is nowhere mandated to be that way.

 

Regards,

 

Christer

 



-----Original Message-----
From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul K= yzivat
Sent: Friday, October 25, 2013 4:28 PM
To: Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators

Inline.

On 10/25/13 2:57 PM, Christer Holmberg wrote:
> Hi,
>
> ....
>
>>> /Example:/
>>>
>>> I support the find-Paul feature, and I insert a FCI:
>>>
>>>      Feature-Caps: *, +g.find-pau= l=3D"sip:pkyzivat@alum.mit.edu"
>>>
>>> Now, in this case the address does NOT point to my entity, but= to
>>> Paul's entity. My entity supports a feature, which provides Pa= ul's address.
>>>
>>> So, if the FCI says:
>>>
>>>      Feature-Caps: *,
>>> +g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+= sip.methods=3D"invite"
>>>
>>> ...it doesn't automatically mean that I can contact Paul using= INVITE.
>>> By default it means that MY entity supports the INVITE method = -
>>> which from the find-paul feature perspective is useless inform= ation.
>>>
>>> So, in the FCI specification for +g.find-paul, I would hav= e to
>>> explictily describe how the FCI works in conjunction with othe= r
>>> FCIs. I would have to explicitly say that, when used together =
>>> +sip.methods, the
>>> +sip.methods indicates which SIP methods I can use to cont= act Paul
>>> (using the address provide in the +g.find-paul FCI).
>>
>> So far I agree.
>>
>> But suppose there is also a find-christer FCI. So we have:
>>
>> Feature-Caps: *
>>    ;+g.find-paul=3D"sip:pkyzivat@alum.mit.= edu"
>>    ;+g.find-paul=3D"sip:christer.holmberg@= ericsson.com"
>>    ;+sip.methods=3D"invite"
>>
>> And both find-paul and find-christer want to define the use of oth= er
>> FCIs. Then things start to become ambiguous.
>>
>> Should the description of find-paul specify what other FCIs "= pertain"
>> to it? Or should the description of sip.methods specify what FCI(s= )
>> provide the address at which it applies? Or both? What if paul and=
>> christer support different methods?
>
> In that case you would need to have two different Feature-Caps header<= br> > fields:
>
>      Feature-Caps:
> *;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.me= thods=3D"invite"
>      Feature-Caps:
> *;+g.find-paul=3D"sip:christer.holmberg@ericsson.com";&#= 43;sip.methods=3D"message"

That seemingly solves the problem, but if the same entity inserts them both= then its a questionable use of Feature-caps isn't it?

> In your example you had two instances of the same FCI (is that even > allowed?),

I did? find-paul and find-christer are two different FCIs.
(But that sort of naming will be troublesome for the registry and for the e= xpert who has to approve entries in it.:-)

  but there could also have been a case with two different
> FCIs, both using +sip.methods, in which case you may have to put t= hem
> into separate Feature-Caps header fields.
>
> These things would have to be clearly specified.

Very definitely.

        Thanks,
        Paul

> Regards,
>
> Christer
>
>
>> Section 5.3.8 in RFC 6809 also says:
>>
>>      "If there is additional informa= tion about the feature-capability
>>         indicator, it is r= ecommended to describe such information.  It can
>>         include, for examp= le, *names of related feature-capability
>> indicators*."
>>
>> So, in your case, I think the +g.3gpp.see_trans FCI specificti= on
>> would have to specify how the FCI is used in conjuntion with other=
>> FCIs, including the +sip.method FCI.
>>
>> Something like: "When the session transfer request is sent to= the
>> address indicated by the FCI value, the +sip.method FCI indica= tes
>> which SIP methods can be used."
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>> *From*: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>> *Sent*: Friday, October 25, 2013 12:01 PM Central Standard Time >> *To*: Andrew Allen; Paul Kyzivat <pkyzivat@alum.mit.edu>; Go= nzalo
>> Camarillo <gonzalo.camarillo@ericsson.com>
>> *Cc*: rlb@ipv.sx <rlb@ipv.sx>; adam@nostrum.com <adam@nos= trum.com>;
>> mary.ietf.barnes@gmail.com <mary.ietf.barnes@gmail.com>
>> *Subject*: RE: New sipcore draft submission
>> draft-allen-sipcore-sip-tree-cap-indicators
>>
>> Hi,
>>
>>>I think we can have an FCI
>>
>>>
>>
>>>Feature-Caps: *;+g.3ggp.sess_trans=3D"sip:foo@example.= com;gr"
>>
>>>
>>
>>>Indicating that the entity supports 3GPP session transfer and t= he
>>>address where you send the session transfer request is  >>>sip:foo@example.com;gr <mailto:foo@example.com;gr>
>>
>> Correct. The FCI itself indicates support of session transfer
>> feature, and the FCI value indicates the address associatd with th= e feature.
>>
>>>Also if I have:
>>
>>>
>>
>>>Feature-Caps: *;+g.3ggp.sess_trans=3Dsip:foo@example.com;gr= ;
>>>+sip.extensions=3D"replaces, tdialog";
>> +sip.methods=3D"invite, refer, bye, options, update, prac= k"
>>
>>>
>>
>>> This means the entity supports 3GPP session transfer and the a= ddress where you send the session transfer request is  sip:foo@example= .com;gr <mailto:= foo@example.com;gr>...
>>
>> Correct.
>>
>>> ...supports the replaces and target dialog extensions and supp= orts the following methods - invite, refer, bye, options, update, prack. >>
>> Technically, what it means is that there is *AN* entity which
>> supports the features listed above, and the address is where you a= re
>> to send the session transfer request in order to trigger the 3GPP =
>> session transfer feature.
>>
>> Regards,
>>
>> Christer
>>
>> *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>> *Sent:* Friday, October 25, 2013 10:25 AM
>> *To:* Paul Kyzivat; Andrew Allen; Gonzalo Camarillo
>> *Cc:* rlb@ipv.sx; adam@nostrum.com; mary.ietf.barnes@gmail.com
>> *Subject:* RE: New sipcore draft submission
>> draft-allen-sipcore-sip-tree-cap-indicators
>>
>> Hi,
>>
>> As Paul said, if one needs to provide address information associat= ed
>> with a FCI, the address information cannot be a FCI of its own. It=
>> needs to be a value of the FCI for which it is associated.
>>
>> Something like:
>>
>> Feature-Caps: *;+audio=3D"sip:foo@example.com"
>>
>> (Also note that the "+" sign is mandatory for all FC= Is - no matter
>> which registry tree they belong to)
>>
>> Regards,
>>
>> Christer
>>
>> ------------------------------------------------------------------= ---
>> ---
>>
>> *From:*Paul Kyzivat [pkyzivat@alum.mit.edu]
>> *Sent:* Friday, 25 October 2013 5:06 PM
>> *To:* Andrew Allen; Gonzalo Camarillo
>> *Cc:* rlb@ipv.sx <mailto:rlb@ipv.sx>; adam@nostrum.com
>> <mailto:a= dam@nostrum.com>; Christer Holmberg;
>> mary.ietf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com>
>> *Subject:* Re: New sipcore draft submission
>> draft-allen-sipcore-sip-tree-cap-indicators
>>
>> Andrew,
>>
>> (I see this is still on the private thread. I'll reply here, but t= his
>> exchange should probably be reposted to the sipcore list as part o= f
>> the public discussion of the draft.)
>>
>> On 10/24/13 10:41 PM, Andrew Allen wrote:
>>>
>>> Paul
>>>
>>> I am happy to do a revision with more details on the semantics= of the capability indicators. However I don't think it should be held to a= very much higher bar than the details in RFC 3840 and the other media feat= ure tag RFCs regarding the meaning of thosetags.
>>
>> Keep in mind that the driving force for the definition of feature =
>> tags in 3840 was in support of callerprefs (3841). So the context = for
>> the use of feature tags was that they would be placed on Contacts = in
>> REGISTER requests. So you can interpret the definitions in that >> context: that a request sent to an AOR using callerprefs can affec= t
>> the choice of which device the request goes to according to the >> capabilities it wants. In that context audio, video, isfocus all m= ake sense.
>>
>> Their use on Contacts in dialogs was derivative to that: because <= br> >> callerpref support is optional, there is no guarantee that the dev= ice
>> you reach via callerprefs will have the capabilities you requested= .
>> So the values in the contact help confirm what you got.
>>
>> Of course they have since been used other ways. And the descriptio= ns
>> of them don't necessarily reflect that. IMO that is a defect due t= o
>> the evolution of use.
>>
>> I'm looking for the same sort of context for use with the feature-= caps.
>>
>> In private discussion you indicated to me that you expected the >> feature caps to be grouped - with one of them giving the URI of th= e
>> device that the other tags apply to. I guess this would end up loo= king something like:
>>
>>     Feature-Caps: *;g.uri=3D"sip:foo@exam= ple.com";audio
>>     Feature-Caps: *;g.uri=3D"sip:bar@exam= ple.com";audio;video;isfocus
>>     Feature-Caps: *;g.uri=3D"sip:baz@exam= ple.com";text
>>
>> (I'm making up g.uri for the example.)
>>
>> And then presumably somebody on the signaling path will "shop= " in the
>> feature caps for the capabilities it wants, and then send a reques= t
>> to that URI, with the expectation that the UA responding will have=
>> those capabilities.
>>
>>> The semantics should be no different than those of  the c= orresponding existing media  feature tag if it is present in the Conta= ct header.
>>
>> Note that 6809 says:
>>
>>      When a SIP entity receives a SIP req= uest, or response, that contains
>>      one or more Feature-Caps header fiel= ds, the feature-capability
>>      indicators in the header field infor= m the entity about the features
>>      and capabilities supported by entiti= es in the SIP message signaling
>>      path.  The procedure by which f= eatures and capabilities are invoked
>>      are outside the scope of this specif= ication and MUST be described by
>>      individual feature-capability indica= tor specifications.
>>
>>      A Feature-Caps header field value ca= nnot convey the address of the
>>      SIP entity that inserted the Feature= -Caps header field.  If
>>      additional data about a supported fe= ature needs to be conveyed, such
>>      as the address of the SIP entity tha= t indicated support of the
>>      feature, then the feature definition= needs to define a way to convey
>>      that information as a value of the a= ssociated feature-capability
>>      indicator.
>>
>> This was discussed at length while that RFC was under consideratio= n.
>> Yet the definitions of the tags in *this* draft don't specify that= .
>>
>>> The registration templates currently reference the RFC 3840 an= d the other RFCs that define the other media feature tags that correspond t= o these feature capability indicators.
>>
>> And those definitions were written to be understood in the context= of
>> 3840/3841. They make sense in that context, but not in *this* cont= ext.
>>
>>          Thanks,
>>          Paul
>>
>>> But if more explicit detail is required then I can add some mo= re text  or alternatively remove the less important ones if they are g= oing to become rat holes. The ones I regard as really important and urgent = are sip.methods, sip.extensions and sip.events  the  meaning of which I think should be quite clear.
>>>
>>> Andrew
>>>
>>> ----- Original Message -----
>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Tim= e
>>> To: Andrew Allen;Gonzalo.Camarillo@ericsson.com
>>> <mailto:Gonzalo.Camarillo@ericsson.com>
>> <Gonzalo.Camarillo@ericsson.com
>> <mailto:Gonzalo.Camarillo@ericsson.com>>
>>> Cc:rlb@ipv.sx <mailto:rlb@ipv.sx> <rlb@ipv.sx <mailto:rlb@ipv.sx>>;
>> adam@nostrum.com <mailto:adam@nostrum.com> <adam@nostrum.com
>> <mailto:a= dam@nostrum.com>>; christer.holmberg@ericsson.com
>> <mailto:christer.holmberg@ericsson.com>
>> <christer.holmberg@ericsson.com
>> <mailto:christer.holmberg@ericsson.com>>; mary.ietf.barnes@g= mail.com
>> <mailto:mary.ietf.barnes@gmail.com> <mary.ietf.barnes@gmail.com
>> <mailto:mary.ietf.barnes@gmail.com>>; Paul Kyzivat
>> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>>
>>> Subject: Re: New sipcore draft submission
>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>
>>> On 10/24/13 4:07 PM, Andrew Allen wrote:
>>>>
>>>> Paul
>>>>
>>>> Ok
>>>>
>>>> So we are basically where I thought we were at when I subm= itted the draft.
>>>>
>>>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus an= yone else who indicates interest) can have some offline discussion in Vanco= uver on whether and how to progress this.
>>>
>>> As I indicated again on the sipcore list, I found the that the= draft
>>> didn't explain nearly enough to allow meaningful use of these.=
>>> I know you replied, and I will continue the conversation there= .
>>> But I will be opposed to these until and unless the draft (and=
>>> notably the descriptions of the tags) are clear about how one = could
>>> figure out what can do in the presence of the tags that one co= uldn't
>>> do without them. AND, that the behavior that suggests doesn't =
>>> "break" sip. (E.g., by advocating a new and incompat= ible way to do
>>> something.)
>>>
>>> We can continue this on the sipcore list.
>>>
>>>        Thanks,
>>>        Paul
>>>
>>>> Andrew
>>>>
>>>> ----- Original Message -----
>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard= Time
>>>> To: Andrew Allen; Gonzalo Camarillo <Gonzalo.Camarillo@= ericsson.com
>>>> <mailto:Gonzalo.Camarillo@ericsson.com>>
>>>> Cc: Richard Barnes (rlb@ipv.sx <mailto:rlb@ipv.sx>) <rlb@ipv.sx
>>>> <mailto= :rlb@ipv.sx>>; Adam
>> Roach (adam@nostrum.com <mailto:adam@nostrum.com>) <adam@nostrum.com
>> <mailto:a= dam@nostrum.com>>; Christer Holmberg
>> (christer.holmberg@ericsson.com
>> <mailto:christer.holmberg@ericsson.com>)
>> <christer.holmberg@ericsson.com
>> <mailto:christer.holmberg@ericsson.com>>; Mary Barnes
>> (mary.ietf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com>) &l= t;
>> mary.ietf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com>><= br> >>>> Subject: Re: New sipcore draft submission
>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>
>>>> On 10/24/13 2:17 PM, Andrew Allen wrote:
>>>>> Paul
>>>>>
>>>>> That is fine. Although Mary in her reply to me seemed = to indicate maybe there was a possibility to use some of the DISPATCH spare= time for a SIPCORE session for this. Is that a possibility?
>>>>>
>>>>> I already replied to your post
>>>>
>>>> I discussed that with Adam. We decided we can't set a prec= edent to
>>>> spin up a session to discuss a draft that hasn't had subst= antial
>>>> (any) list discussion.
>>>>
>>>> But list discussion is always welcome.
>>>>
>>>>       Sorry,
>>>>       Paul
>>>>
>>>>> Andrew
>>>>>
>>>>> -----Original Message-----
>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>>> Sent: Thursday, October 24, 2013 1:31 PM
>>>>> To: Andrew Allen; Gonzalo Camarillo
>>>>> Cc: Richard Barnes (rlb@ipv.sx <mailto:rlb@ipv.sx>); Adam Roach
>>>>> (adam@nostrum.com
>> <mailto:a= dam@nostrum.com>); Christer Holmberg
>> (christer.holmberg@ericsson.com
>> <mailto:christer.holmberg@ericsson.com>)
>>>>> Subject: Re: New sipcore draft submission
>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>
>>>>> Andrew,
>>>>>
>>>>> I spoke with Mary about it, and we concluded that disp= atch isn't right for this. (In addition to being clearly sipcore, it didn't= meet the deadline for dispatch.) I was wrong to encourage you that way. >>>>>
>>>>> So no official live discussion in Vancouver. (But info= rmal
>>>>> discussion
>>>>> fine.)
>>>>>
>>>>> I'll resend my private comments to the sipcore list to= kickstart some discussion there.
>>>>>
>>>>>      Thanks,
>>>>>      Paul
>>>>>
>>>>> On 10/24/13 1:01 PM, Andrew Allen wrote:
>>>>>> I just emailed Mary asking for agenda time. Should= I cancel that request?
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsso= n.com]
>>>>>> Sent: Thursday, October 24, 2013 1:00 PM
>>>>>> To: Paul Kyzivat
>>>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx
>>>>>> <mailto:rlb@ipv.sx>); Adam Roach (adam@nostrum.com
>>>>>> <mailto:adam@nostrum.com>); Christer Holmberg
>> (christer.holmberg@ericsson.com
>> <mailto:christer.holmberg@ericsson.com>)
>>>>>> Subject: Re: New sipcore draft submission
>>>>>> draft-allen-sipcore-sip-tree-cap-indicators
>>>>>>
>>>>>> Hi Paul,
>>>>>>
>>>>>> given that you think this belongs to SIPCORE, I do= not see the need to run it through DISPATCH. Please, start technical discu= ssions on the draft on the SIPCORE list.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Gonzalo
>>>>>>
>>>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote:
>>>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote:
>>>>>>>> Paul
>>>>>>>>
>>>>>>>> Thanks for reviewing the draft already and= giving me early feedback.
>>>>>>>>
>>>>>>>> My responses below inline (prepended with = [AA).
>>>>>>>>
>>>>>>>> Can I ask the ADs to determine ASAP if thi= s needs to go to
>>>>>>>> DISPATCH first or not. As outlined below m= y view is that it is
>>>>>>>> unnecessary for every little thing to go t= o DISPATCH as this
>>>>>>>> just creates additional delay and overhead= . If it is to be
>>>>>>>> discussed in DISPATCH then I definitely wo= uld want agenda time atIETF#88 for this.
>>>>>>>
>>>>>>> Having now seen Andrew's responses to my initi= al questions, I
>>>>>>> think this
>>>>>>> *needs* to be carefully considered by sipcore.= IMO this has the
>>>>>>> potential to create a dialect of sip that is i= ncompatible with
>>>>>>> normal usage. (Maybe IMS has already done that= . But this will
>>>>>>> make it
>>>>>>> worse.)
>>>>>>>
>>>>>>> But if there is a desire to discuss it publicl= y in Vancouver
>>>>>>> then dispatch is the opportunity and so some d= iscussion on the
>>>>>>> dispatch list in advance of that would be appr= opriate.
>>>>>>>
>>>>>>> I'll defer to the ADs on this.
>>>>>>>
>>>>>>> More inline.
>>>>>>>
>>>>>>>> Andrew
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.= sx
>>>>>>>> <mailto:rlb@ipv.sx>); Gonzalo Camarillo
>>>>>>>> (Gonzalo.Camarillo@ericsson.com
>>>>>>>> <mailto:Gonzalo.Camarillo@ericsson.com>= );
>> Adam Roach (adam@nostrum.com <mailto:adam@nostrum.com>)
>>>>>>>> Subject: Re: New sipcore draft submission =
>>>>>>>> draft-allen-sipcore-sip-tree-cap-indicator= s
>>>>>>>>
>>>>>>>> Andrew,
>>>>>>>>
>>>>>>>> On a legalistic note, its questionable to = me whether this kind
>>>>>>>> of action falls within the scope of sipcor= e. OTOH, among
>>>>>>>> existing wgs, sipcore is probably the best= suited to discuss
>>>>>>>> the proposal. We could take it to DISPATCH= . I think DISPATCH
>>>>>>>> has extra time in its agenda for Vancouver= , so that might be
>>>>>>>> one option for you. But then I don't know = where dispatch would
>>>>>>>> dispatch it. It may be that AD sponsored i= s the best way to go.
>>>>>>>>
>>>>>>>> [AA] It seemed to me that sipcore was the = right place. This
>>>>>>>> draft registers feature-capability indicat= ors in a registry
>>>>>>>> that was created by a sipcore RFC (RFC 680= 9). You could in my
>>>>>>>> view make an argument that this should eve= n have been done as part of RFC 6809.
>>>>>>>
>>>>>>> If this was just a matter of registering some = new feature caps
>>>>>>> that were not controversial, then I don't thin= k sipcore needs to be involved.
>>>>>>>
>>>>>>> But as I mentioned above, I do consider these = controversial.
>>>>>>>
>>>>>>>> Discussing it now on the dispatch list wou= ld be a good start
>>>>>>>> toward discussing it at the dispatch sessi= on.
>>>>>>>>
>>>>>>>> [AA] Can I ask the ADs to determine if thi= s needs to go to
>>>>>>>> DISPATCH first or not. My view is that it = is unnecessary for
>>>>>>>> every little thing to go to DISPATCH as th= is just creates additional delay and overhead.
>>>>>>>> This just registers some indicators in an = existing IANA
>>>>>>>> registry and is not (or should not be IMHO= ) a major project.
>>>>>>>
>>>>>>> To me this is a matter of whether you want to = be opportunistic.
>>>>>>> If this went to dispatch I would now recommend= that it be
>>>>>>> dispatched to sipcore. So its a matter of whet= her you want to
>>>>>>> talk about it in the dispatch meeting.
>>>>>>>
>>>>>>>> Regarding substance, this draft troubles m= e. It takes
>>>>>>>> feature-caps in exactly the direction that= I found most
>>>>>>>> concerning about the mechanism in the firs= t place.
>>>>>>>>
>>>>>>>> Your draft partitions the existing media f= eature tags into two
>>>>>>>> sets
>>>>>>>> - those that would be useful as feature-ca= pability-indicators,
>>>>>>>> and those that aren't. But I see no explan= ation of the criteria
>>>>>>>> used to make this distinction, nor can I t= hink of one.
>>>>>>>>
>>>>>>>> [AA] I based this decision on the followin= g criteria: If a
>>>>>>>> feature tag was potentially at all useful = for an intermediary
>>>>>>>> to indicate it then include it in the regi= stry. The ones not
>>>>>>>> included are either directly associated wi= th the user
>>>>>>>> (intermediaries are not  directly ass= ociated with the user) or
>>>>>>>> would only ever have one value (e.g automa= ta).  I am not sure
>>>>>>>> that every feature-capability indicator pr= oposed to be
>>>>>>>> registered is actually useful but then I d= on't think every
>>>>>>>> media feature tag registered by RFC 3840 i= s either (I doubt
>>>>>>>> very much if there are implementation usin= g the sip.application
>>>>>>>> or sip.control feature tags). I don't thin= k RFC 3840 goes into
>>>>>>>> a lot of details justifying of ever regist= ered media feature
>>>>>>>> tag and specifying the details of how they= would be used
>>>>>>>> either.  I am willing to remove any f= eature-capability indicators that are controversial except that I think we = definitely need sip.extensions, sip.methods and sip.events.
>>>>>>>> There is a significant overhead to writing= an
>>>>>>> d progressing internet drafts so my view is le= ts register all
>>>>>>> that might be remotely useful in the same docu= ment.
>>>>>>>
>>>>>>> The judgement of "useful" is reasona= ble. But I still can't
>>>>>>> discern what the use is from the iana registra= tion descriptions.
>>>>>>>
>>>>>>>> For the ones that you have requested featu= re capability
>>>>>>>> indicators, I cannot figure out what using= them would mean. For
>>>>>>>> example, when I see isFocus on a Contact h= eader I know I am in
>>>>>>>> a conference, and that I can subscribe to = the conference event
>>>>>>>> package at the contact URI. If I see isFoc= us in a Feature-Caps header, what does it mean?
>>>>>>>> What can I do once I know this?
>>>>>>>>
>>>>>>>> Section 5.14 of this draft says:
>>>>>>>>
>>>>>>>>       &= nbsp;     This Feature-capability indicator indicates t= hat the intermediary
>>>>>>>>       &= nbsp;     is a conference server, also known as a focus= , and is capable of
>>>>>>>>       &= nbsp;     mixing together the media for all calls to th= e same URI.
>>>>>>>> ...
>>>>>>>>       &= nbsp;        Examples of typical use: A = conference bridge
>>>>>>>> indicating that it
>>>>>>>>       &= nbsp;        is a conference bridge and = is capable of acting
>>>>>>>> as a conference
>>>>>>>>       &= nbsp;        focus for this session.
>>>>>>>>
>>>>>>>> [AA] the presence of isfocus in a Feature-= Caps header field
>>>>>>>> means that a UA can initiate a conference = by sending a REFER
>>>>>>>> request to the intermediary to invite anot= her user and create a
>>>>>>>> multi user conference from the 1-1 session= .
>>>>>>>>
>>>>>>>> Note that Feature-Caps doesn't indicate wh= ich entity has this
>>>>>>>> capability, only that something does. And = since this would
>>>>>>>> presumably only be used if it wasn't the U= AC of the request,
>>>>>>>> sending a subscribe to the contact address= of the UAC wouldn't make sense.
>>>>>>>>
>>>>>>>> [AA] Yes the GRUU of the intermediary woul= d be needed but I
>>>>>>>> consider this application specific and so = this would be
>>>>>>>> included in a feature tag registered in th= e global tree as
>>>>>>>> stated in the draft "RFC 6809 [1] pro= vides that addresses of
>>>>>>>> intermediaries can be communicated as a va= lue of an associated
>>>>>>>> feature-capability indicator so it would b= e appropriate to
>>>>>>>> define feature capability indicators as pa= rt of the global tree
>>>>>>>> to communicate the GRUU of the intermediar= y and hence this is
>>>>>>>> outside the scope of this document."&= nbsp; - RFC 6809 states " If
>>>>>>>> additional data about a supported feature = needs to be conveyed,
>>>>>>>> such as the address of the SIP entity that= indicated support of
>>>>>>>> the feature, then the feature definition n= eeds to define a way
>>>>>>>> to convey that information as a value of t= he associated
>>>>>>>> feature-capability indicator." Howeve= r I think the SIP specific
>>>>>>>> capability indicators such as methods, ext= ensions and events
>>>>>>>> should appropriately be registered in the = SIP tree not as
>>>>>>>> proprietary indicator
>>>>>>> s in the global tree.
>>>>>>>
>>>>>>> So you have defined a sip tree feature tag tha= t is only useful
>>>>>>> in conjunction with another feature tag from t= he global tree.
>>>>>>> And the description of this feature tag doesn'= t even mention that.
>>>>>>>
>>>>>>> And this all implies a completely non-standard= call model -
>>>>>>> doing conferencing in a way inconsistent with = RFC 4579.
>>>>>>>
>>>>>>> ISTM that if 4579 doesn't work for you then yo= u should be back
>>>>>>> proposing extensions/revisions to it.
>>>>>>>
>>>>>>>> If there is a conference bridge in the sig= naling path, then I
>>>>>>>> would expect it to be the UAC.
>>>>>>>>
>>>>>>>> [AA] Although a "standard" way t= o invoke a conference is to
>>>>>>>> send a REFER to the other UAs to invite th= em to the conference
>>>>>>>> focus,  in many deployments a scenari= o exists where a call
>>>>>>>> involves an IP-PBX or Telephony Applicatio= n Server (TAS) that
>>>>>>>> can act as a focus for the conference. A p= articipant of a call
>>>>>>>> can then create a conference by sending a = REFER request in
>>>>>>>> dialog to the IP-PBX or TAS to use 3PCC to= Invite other users to a conference. Reasons for this are 1.
>>>>>>>> Not all UAs support REFER,
>>>>>>>
>>>>>>> So you are saying the intermediary isn't a foc= us (its a B2BUA),
>>>>>>> but it *could become* a focus.
>>>>>>>
>>>>>>> The concept that a dialog may contain intermed= iaries that can be
>>>>>>> addressed to do stuff is not part of any sip s= tandard that I am
>>>>>>> aware of. I don't care too much as long as the= "stuff" is
>>>>>>> application stuff that is outside the scope of= sip. But when it
>>>>>>> is alternative ways to do stuff that sip suppo= rts, then I get upset.
>>>>>>>
>>>>>>>> 2. Many SBCs reject REFER requests going o= utside domains
>>>>>>>> because of the potential for charging frau= d (referring to a
>>>>>>>> premium rate number
>>>>>>>> etc) 3. A User receiving a REFER and then = using an INVITE to
>>>>>>>> join the conference may be charged for ini= tiating  the call
>>>>>>>> when the scenario is that the initiator of= the conference should be charged.
>>>>>>>> 4. No need to obtain and distribute confer= ence URIs.
>>>>>>>> Problem is how to achieve the same behavio= r without dialog
>>>>>>>> reuse which has been deprecated by RFC 666= 5?
>>>>>>>
>>>>>>> Then maybe the problem needs to be brought up,= and a standard
>>>>>>> solution proposed, rather than simply enabling= a proprietary mechanism.
>>>>>>>
>>>>>>>> As another example, consider section 5.1:<= br> >>>>>>>>
>>>>>>>>       &= nbsp;     Descrition:
>>>>>>>>       &= nbsp;     This Feature-capability indicator indicates t= hat the intermediary
>>>>>>>>       &= nbsp;     supports audio as a streaming media type.
>>>>>>>> ...
>>>>>>>>       &= nbsp;        Examples of typical use: An= IP PBX indicating that it is
>>>>>>>>       &= nbsp;        capable of accepting and in= itiating sessions with audio as a
>>>>>>>>       &= nbsp;        streaming media type.
>>>>>>>>
>>>>>>>> This definition *implies* an assumption ab= out the working
>>>>>>>> environment
>>>>>>>> - one that AFAIK is new. It implies that y= ou need to know that
>>>>>>>> intermediaries support a media type before= you can use it.
>>>>>>>> Would it be bad if there were no intermedi= aries, and so none indicated this?
>>>>>>>> What if some intermediary *did* indicate s= upport, but some
>>>>>>>> other doesn't, but doesn't indicate that i= t doesn't?
>>>>>>>>
>>>>>>>> Bottom line: how would the presence or abs= ence of this feature
>>>>>>>> tag affect subsequent usage?
>>>>>>>>
>>>>>>>> [AA] The absence of the streaming types do= es not indicate that
>>>>>>>> the intermediary does not support the medi= a type and SDP offer
>>>>>>>> answer will ultimately determine what can = or cannot be used if
>>>>>>>> another session is initiated involving the= intermediary.
>>>>>>>> However the presence of the media type in = a Feature-caps header
>>>>>>>> field does explictly confirm that the inte= rmediary does support
>>>>>>>> the media type and in the scenario where a= UA has a choice of
>>>>>>>> multiple intermediaries it could use for a= conference it might
>>>>>>>> choose to use the one that explicitly indi= cates it supports the media types the UA wants to use.
>>>>>>>
>>>>>>> So the UA will be able to discover that *some*= intermediary
>>>>>>> supports media it is interested in. And it can= tell that *some*
>>>>>>> intermediary says it is a focus. It doesn't kn= ow if they are the same intermediary.
>>>>>>>
>>>>>>> And then via some other feature tag it obtains= the URI of *some*
>>>>>>> intermediary on the signaling path. Or maybe i= t gets more than
>>>>>>> one of these.
>>>>>>>
>>>>>>> It then makes a leap of faith and conflates al= l those things, to
>>>>>>> determine that the URI identifies a focus that= supports this media type.
>>>>>>>
>>>>>>> Even then, exactly what does that mean? It may= or may not mean
>>>>>>> that it supports mixing that media type in a c= onference.
>>>>>>>
>>>>>>>> As I stated already I don't care that much= about these
>>>>>>>> streaming media types.
>>>>>>>
>>>>>>>> I could go on, but this is enough for now.=
>>>>>>>>
>>>>>>>> [AA] My motivation for this is that curren= tly 3GPP are updating
>>>>>>>> their specifications to use RFC 6665 inste= ad of RFC 3265.
>>>>>>>
>>>>>>>> 3GPP has a lot of dialog reuse with SUBSCR= IBE and REFER with
>>>>>>>> intermediaries accepting the REFER or SUBS= CRIBE request rather
>>>>>>>> than forwarding it all the way to the remo= te UA.
>>>>>>>
>>>>>>> And 6665 deprecates dial reuse in most of thos= e cases.
>>>>>>> Without dialog reuse, the intermediaries don't= get an
>>>>>>> opportunity to intercept those.
>>>>>>>
>>>>>>>> In order to know that an intermediary supp= orts the target
>>>>>>>> dialog mechanism  needed for a REFER = request sent outside the
>>>>>>>> dialog to work we need sip.extensions as a= feature-capability
>>>>>>>> indicator. In order to know that the neede= d event package is
>>>>>>>> supported by the intermediary so we can SU= BSCROBE outside the
>>>>>>>> dialog to an intermediary we need sip.even= ts as a feature-capability indicator.
>>>>>>>
>>>>>>> Then I think you should be back here with a pr= oblem statement
>>>>>>> and a request for how to get sip to solve it.<= br> >>>>>>>
>>>>>>> And you should touch base with Christer on thi= s. He may have a
>>>>>>> different opinion on the relevance of feature-= caps as a solution.
>>>>>>>
>>>>>>>        = ; Thanks,
>>>>>>>        = ; Paul
>>>>>>>
>>>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>>> Adam, Paul, Richard, Gonzalo
>>>>>>>>>
>>>>>>>>> I have submitted a new draft to sipcor= e  to register a number
>>>>>>>>> of feature capability indicators in th= e SIP tree (based upon
>>>>>>>>> some of the existing SIP media feature= tags). The draft can be found at:
>>>>>>>>>
>>>>>>>>>http://www.iet= f.org/id/draft-allen-sipcore-sip-tree-cap-indicators-00.
>>>>>>>>> txt
>>>>>>>>>
>>>>>>>>> Since there will not be a sipcore sess= ion at IETF#88  can we
>>>>>>>>> have an offline discussion on how to p= rogress this draft
>>>>>>>>> (which hopefully is fairly straightfor= ward as it just
>>>>>>>>> registers feature capabilities indicat= ors with IANA). I
>>>>>>>>> wouldn't want to have to wait until Ma= rch next year for a decision on progressing this.
>>>>>>>>>
>>>>>>>>> Andrew
>>>>>>>>>
>>>>>>>>> --------------------------------------= ------------------------
>>>>>>>>> -----
>>>>>>>>> -
>>>>>>>>> - This transmission (including any att= achments) may contain
>>>>>>>>> confidential information, privileged m= aterial (including
>>>>>>>>> material protected by the solicitor-cl= ient or other applicable
>>>>>>>>> privileges), or constitute non-public = information. Any use of
>>>>>>>>> this information by anyone other than = the intended recipient
>>>>>>>>> is prohibited. If you have received th= is transmission in
>>>>>>>>> error, please immediately reply to the= sender and delete this
>>>>>>>>> information from your system. Use, dis= semination,
>>>>>>>>> distribution, or reproduction of this = transmission by unintended recipients is not authorized and may be unlawful= .
>>>>>>>>
>>>>>>>> ------------------------------------------= ---------------------
>>>>>>>> -----
>>>>>>>> - This transmission (including any attachm= ents) may contain
>>>>>>>> confidential information, privileged mater= ial (including
>>>>>>>> material protected by the solicitor-client= or other applicable
>>>>>>>> privileges), or constitute non-public info= rmation. Any use of
>>>>>>>> this information by anyone other than the = intended recipient is
>>>>>>>> prohibited. If you have received this tran= smission in error,
>>>>>>>> please immediately reply to the sender and= delete this
>>>>>>>> information from your system. Use, dissemi= nation, distribution,
>>>>>>>> or reproduction of this transmission by un= intended recipients is not authorized and may be unlawful.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --------------------------------------------------= ---------------
>>>>>> ---- This transmission (including any attachments)= may contain
>>>>>> confidential information, privileged material (inc= luding material
>>>>>> protected by the solicitor-client or other applica= ble
>>>>>> privileges), or constitute non-public information.= Any use of
>>>>>> this informationby anyone other than the intended = recipient is
>>>>>> prohibited. If you have
>> received this transmission in error, please immediately reply to t= he
>> sender and delete this information from your system. Use,
>> dissemination, distribution, or reproduction of this transmission = by
>> unintended recipients is not authorized and may be unlawful.
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------= ------------
>>>>> --- This transmission (including any attachments) may = contain
>>>>> confidential information, privileged material (includi= ng material
>>>>> protected by the solicitor-client or other applicable = privileges),
>>>>> or constitute non-public information. Any use of this =
>>>>> informationby anyone other than the intended recipient= is
>>>>> prohibited. If you have
>> received this transmission in error, please immediately reply to t= he
>> sender and delete this information from your system. Use,
>> dissemination, distribution, or reproduction of this transmission = by
>> unintended recipients is not authorized and may be unlawful.
>>>>>
>>>>>
>>>>
>>>> ----------------------------------------------------------= ---------
>>>> -- This transmission (including any attachments) may conta= in
>>>> confidential information, privileged material (including m= aterial
>>>> protected by the solicitor-client or other applicable priv= ileges),
>>>> or constitute non-public information. Any use of this info= rmationby
>>>> anyone other than the intended recipient is prohibited. If= you have
>> received this transmission in error, please immediately reply to t= he
>> sender and delete this information from your system. Use,
>> dissemination, distribution, or reproduction of this transmission = by
>> unintended recipients is not authorized and may be unlawful.
>>>>
>>>>
>>>
>>> --------------------------------------------------------------= ------
>>> - This transmission (including any attachments) may contain >>> confidential information, privileged material (including mater= ial
>>> protected by the solicitor-client or other applicable privileg= es),
>>> or constitute non-public information. Any use of this informat= ionby
>>> anyone other than the intended recipient is prohibited. If you= have
>> received this transmission in error, please immediately reply to t= he
>> sender and delete this information from your system. Use,
>> dissemination, distribution, or reproduction of this transmission = by
>> unintended recipients is not authorized and may be unlawful.
>>>
>>>
>>
>> ------------------------------------------------------------------= ---
>> This transmission (including any attachments) may contain
>> confidential information, privileged material (including material =
>> protected by the solicitor-client or other applicable privileges),= or
>> constitute non-public information. Any use of this information by =
>> anyone other than the intended recipient is prohibited. If you hav= e
>> received this transmission in error, please immediately reply to t= he
>> sender and delete this information from your system. Use,
>> dissemination, distribution, or reproduction of this transmission = by
>> unintended recipients is not authorized and may be unlawful.
>> ------------------------------------------------------------------= ---
>> This transmission (including any attachments) may contain
>> confidential information, privileged material (including material =
>> protected by the solicitor-client or other applicable privileges),= or
>> constitute non-public information. Any use of this information by =
>> anyone other than the intended recipient is prohibited. If you hav= e
>> received this transmission in error, please immediately reply to t= he
>> sender and delete this information from your system. Use,
>> dissemination, distribution, or reproduction of this transmission = by
>> unintended recipients is not authorized and may be unlawful.
>>
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>>https://www.ietf.org/mailman/listinfo/sipcore
>>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

--_000_7594FB04B1934943A5C02806D1A2204B1C4F7363ESESSMB209erics_-- From christer.holmberg@ericsson.com Fri Oct 25 14:04:46 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074BE11E81DC for ; Fri, 25 Oct 2013 14:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.571 X-Spam-Level: X-Spam-Status: No, score=-5.571 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSfV4-sTBOBp for ; Fri, 25 Oct 2013 14:04:39 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EBDC011E81E4 for ; Fri, 25 Oct 2013 14:04:37 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-89-526adce43819 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7B.37.03802.4ECDA625; Fri, 25 Oct 2013 23:04:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Fri, 25 Oct 2013 23:04:36 +0200 From: Christer Holmberg To: Paul Kyzivat , Andrew Allen , SIPCORE Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cE1yVFOeZTcSEqdPCNN7XweJJoF58BKgAAAXnE= Date: Fri, 25 Oct 2013 21:04:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F7392@ESESSMB209.ericsson.se> References: <526A7ADF.8010106@alum.mit.edu> , <526ABAAC.1000304@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C4F70BF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4F70E4@ESESSMB209.ericsson.se>, <526AD528.8020108@alum.mit.edu> In-Reply-To: <526AD528.8020108@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4F7392ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje6TO1lBBj+/mFncn7eV0WLFhgOs Fl9/bGJzYPb4+/4Dk8eshrXsHkuW/GQKYI7isklJzcksSy3St0vgynhzt5GtYK9oxb8PS5gb GM8JdTFyckgImEgc/fORDcIWk7hwbz2YLSRwmFGicZ9nFyMXkL2EUWLR98/sXYwcHGwCFhLd /7RBakQEciT2bjzFBGILCyRKrD2wgB0iniTx/+xTJgjbSuL0vC3MIK0sAqoSe24Gg4R5BXwl 3vSfZ4dY9YlJ4v1XLxCbU0BH4u2p/ywgNiPQOd9PrQEbwywgLnHryXwmiDMFJJbsOc8MYYtK vHz8jxXCVpL4seESC0R9vsSztzfYIXYJSpyc+YRlAqPILCSjZiEpm4WkDCKuJ3Fj6hQ2CFtb YtnC18wQtq7EjH+HoGqsJc5ObmNHVrOAkWMVI3tuYmZOernRJkZgjB3c8lt1B+OdcyKHGKU5 WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBjG97RhobRgwINTrBLB82fMb/ux KNs/yebXhiWzOcu+PmgzEV3J0L9gwtu9ov4rL3EoxQQ4eb5V/pd+Sv1w2NqnGi0bUq5PCtyj maZeXLtlLfOb+Seapl5fvnWTUIP5x/Nt225x3hbbO3Ptq0VmBgH7tqkaHMieOo2vNCb7gpd9 VEeY0tYZS9KVWIozEg21mIuKEwG/8GjSfwIAAA== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 21:04:46 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4F7392ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >> As a side note, you can also indicate a SIP method as a URI parameter: >> >> sip:transfer@example.com;method=3Drefer > > Yes. But *that* has its own semantics. It means that when you use that > URI in a request, the method should be REFER. You could repeat the address, with different method values in each. Yes, it WOULD be an ugly hack :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4F7392ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <479311430C817147B7202FB15F2FDF25@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

>> As a side not= e, you can also indicate a SIP method as a URI parameter:
>>
>> sip:transfer@example.com;method=3Drefer
>
> Yes. But *that* has its own semantics. It means that when you use that=
> URI in a request, the method should be REFER.

 

You could repeat the a= ddress, with different method values in each.

 

Yes, it WOULD be&= nbsp;an ugly hack :)

 

Regards,=

 

Christer=

 

--_000_7594FB04B1934943A5C02806D1A2204B1C4F7392ESESSMB209erics_-- From aallen@blackberry.com Fri Oct 25 17:16:12 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6854C11E81CE for ; Fri, 25 Oct 2013 17:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJrmcy0Z6DH9 for ; Fri, 25 Oct 2013 17:16:04 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 997BE11E81CD for ; Fri, 25 Oct 2013 17:15:59 -0700 (PDT) Received: from xct103ads.rim.net ([10.67.111.44]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 25 Oct 2013 20:15:53 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.03.0123.003; Fri, 25 Oct 2013 19:15:53 -0500 From: Andrew Allen To: "christer.holmberg@ericsson.com" , "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cE1Z0rvQ+d3A0KchPJXMl5vjJoGO+2A///hoFk= Date: Sat, 26 Oct 2013 00:15:52 +0000 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4F7392@ESESSMB209.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338E3CEE2XMB104ADSrimnet_" MIME-Version: 1.0 Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 00:16:12 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338E3CEE2XMB104ADSrimnet_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 DQpDaHJpc3Rlcg0KDQpJdCBnZXRzIHdvcnNlIC0gaG93IHdvdWxkIHlvdSBpbmRpY2F0ZSBzdXBw b3J0IGZvciBleHRlbnNpb25zIGFuZCBldmVudCBwYWNrYWdlcyB1c2luZyB0aGUgVVJJIG1lY2hh bmlzbT8NCg0KSSB0aGluayB3ZSBuZWVkIHRvIGtlZXAgd2l0aCB0aGUgaWRlYSB0aGF0IHRoaW5n cyBhcmUgZ3JvdXBlZCB0b2dldGhlciB1bmRlciBhIHNpbmdsZSBGZWF0dXJlLUNhcHMgaGVhZGVy IGZpZWxkLg0KDQpBbmRyZXcNCg0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMjUsIDIw MTMgMDQ6MDQgUE0gQ2VudHJhbCBTdGFuZGFyZCBUaW1lDQpUbzogUGF1bCBLeXppdmF0IDxwa3l6 aXZhdEBhbHVtLm1pdC5lZHU+OyBBbmRyZXcgQWxsZW47IFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSRTogW3NpcGNvcmVdIE5ldyBzaXBjb3JlIGRyYWZ0IHN1Ym1pc3Npb24g ZHJhZnQtYWxsZW4tc2lwY29yZS1zaXAtdHJlZS1jYXAtaW5kaWNhdG9ycw0KDQoNCkhpLA0KDQoN Cg0KPj4gQXMgYSBzaWRlIG5vdGUsIHlvdSBjYW4gYWxzbyBpbmRpY2F0ZSBhIFNJUCBtZXRob2Qg YXMgYSBVUkkgcGFyYW1ldGVyOg0KPj4NCj4+IHNpcDp0cmFuc2ZlckBleGFtcGxlLmNvbTttZXRo b2Q9cmVmZXINCj4NCj4gWWVzLiBCdXQgKnRoYXQqIGhhcyBpdHMgb3duIHNlbWFudGljcy4gSXQg bWVhbnMgdGhhdCB3aGVuIHlvdSB1c2UgdGhhdA0KPiBVUkkgaW4gYSByZXF1ZXN0LCB0aGUgbWV0 aG9kIHNob3VsZCBiZSBSRUZFUi4NCg0KDQoNCllvdSBjb3VsZCByZXBlYXQgdGhlIGFkZHJlc3Ms IHdpdGggZGlmZmVyZW50IG1ldGhvZCB2YWx1ZXMgaW4gZWFjaC4NCg0KDQoNClllcywgaXQgV09V TEQgYmUgYW4gdWdseSBoYWNrIDopDQoNCg0KDQpSZWdhcmRzLA0KDQoNCg0KQ2hyaXN0ZXINCg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVu dHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRl cmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVu dCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJs aWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3Ro ZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkg cmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3Vy IHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlv biBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1 dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4K --_000_BBF5DDFE515C3946BC18D733B20DAD2338E3CEE2XMB104ADSrimnet_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQgLS0+DQo8 bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD11dGYtOCI+DQo8c3R5bGU+LkVtYWlsUXVvdGUgewoJUEFERElORy1MRUZUOiA0cHQ7IE1BUkdJ Ti1MRUZUOiAxcHQ7IEJPUkRFUi1MRUZUOiAjODAwMDAwIDJweCBzb2xpZAp9Cjwvc3R5bGU+PHN0 eWxlIGlkPSJvd2FQYXJhU3R5bGUiPlAgewoJTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tVE9Q OiAwcHgKfQo8L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgb2NzaT0iMCIgZnBzdHlsZT0iMSI+DQo8 Zm9udCBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGJyPg0KQ2hyaXN0ZXI8 YnI+DQo8YnI+DQpJdCBnZXRzIHdvcnNlIC0gaG93IHdvdWxkIHlvdSBpbmRpY2F0ZSBzdXBwb3J0 IGZvciBleHRlbnNpb25zIGFuZCBldmVudCBwYWNrYWdlcyB1c2luZyB0aGUgVVJJIG1lY2hhbmlz bT88YnI+DQo8YnI+DQpJIHRoaW5rIHdlIG5lZWQgdG8ga2VlcCB3aXRoIHRoZSBpZGVhIHRoYXQg dGhpbmdzIGFyZSBncm91cGVkIHRvZ2V0aGVyIHVuZGVyIGEgc2luZ2xlIEZlYXR1cmUtQ2FwcyBo ZWFkZXIgZmllbGQuPGJyPg0KPGJyPg0KQW5kcmV3PC9mb250Pjxicj4NCiZuYnNwOzxicj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxmb250IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48Yj5G cm9tPC9iPjogQ2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb21dDQo8YnI+DQo8Yj5TZW50PC9iPjogRnJpZGF5LCBPY3RvYmVyIDI1LCAyMDEzIDA0 OjA0IFBNIENlbnRyYWwgU3RhbmRhcmQgVGltZTxicj4NCjxiPlRvPC9iPjogUGF1bCBLeXppdmF0 ICZsdDtwa3l6aXZhdEBhbHVtLm1pdC5lZHUmZ3Q7OyBBbmRyZXcgQWxsZW47IFNJUENPUkUgJmx0 O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7DQo8YnI+DQo8Yj5TdWJqZWN0PC9iPjogUkU6IFtzaXBjb3Jl XSBOZXcgc2lwY29yZSBkcmFmdCBzdWJtaXNzaW9uIGRyYWZ0LWFsbGVuLXNpcGNvcmUtc2lwLXRy ZWUtY2FwLWluZGljYXRvcnMNCjxicj4NCjwvZm9udD4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxmb250 IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7Ij48L3NwYW4+PC9mb250Pg0K PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFRhaG9tYTsgZm9u dC1zaXplOiAxMHB0OyBkaXJlY3Rpb246IGx0cjsiPg0KPHA+SGksPC9wPg0KPHA+PGZvbnQgc2l6 ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPjwvc3Bhbj48L2ZvbnQ+Jm5ic3A7 PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPiZn dDsmZ3Q7IEFzIGEgc2lkZSBub3RlLCB5b3UgY2FuIGFsc28gaW5kaWNhdGUgYSBTSVAgbWV0aG9k IGFzIGEgVVJJIHBhcmFtZXRlcjo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IHNpcDp0cmFu c2ZlckBleGFtcGxlLmNvbTttZXRob2Q9cmVmZXI8YnI+DQomZ3Q7PGJyPg0KJmd0OyBZZXMuIEJ1 dCAqdGhhdCogaGFzIGl0cyBvd24gc2VtYW50aWNzLiBJdCBtZWFucyB0aGF0IHdoZW4geW91IHVz ZSB0aGF0IDxicj4NCiZndDsgVVJJIGluIGEgcmVxdWVzdCwgdGhlIG1ldGhvZCBzaG91bGQgYmUg UkVGRVIuPC9zcGFuPjwvZm9udD48L3A+DQo8cD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMHB0OyI+PC9zcGFuPjwvZm9udD4mbmJzcDs8L3A+DQo8cD48Zm9udCBzaXpl PSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+WW91IGNvdWxkIHJlcGVhdCB0aGUg YWRkcmVzcywgd2l0aCBkaWZmZXJlbnQgbWV0aG9kIHZhbHVlcyBpbiBlYWNoLjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsi Pjwvc3Bhbj48L2ZvbnQ+Jm5ic3A7PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTBwdDsiPlllcywgaXQmbmJzcDtXT1VMRCBiZSZuYnNwO2FuIHVnbHkgaGFj ayA6KTwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHA+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTBwdDsiPjwvc3Bhbj48L2ZvbnQ+Jm5ic3A7PC9wPg0KPHA+PGZvbnQgc2l6ZT0i MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsiPlJlZ2FyZHMsPC9zcGFuPjwvZm9udD48 L3A+DQo8cD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+PC9z cGFuPjwvZm9udD4mbmJzcDs8L3A+DQo8cD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMHB0OyI+Q2hyaXN0ZXI8L3NwYW4+PC9mb250PjwvcD4NCjxwPjxmb250IHNpemU9 IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250Pjwv cD4NCjwvZGl2Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPlRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcg YW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHBy aXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNv bGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3Rp dHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24g YnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNl IGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0 aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBv ciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGll bnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuPGJyPjwvYm9keT4NCjwv aHRtbD4NCg== --_000_BBF5DDFE515C3946BC18D733B20DAD2338E3CEE2XMB104ADSrimnet_-- From christer.holmberg@ericsson.com Fri Oct 25 23:11:16 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D266621E80CF for ; Fri, 25 Oct 2013 23:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.752 X-Spam-Level: X-Spam-Status: No, score=-3.752 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAIAQd-56Q7Z for ; Fri, 25 Oct 2013 23:11:10 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id B201E11E8245 for ; Fri, 25 Oct 2013 23:11:09 -0700 (PDT) X-AuditID: c1b4fb38-b7f178e00000233b-e1-526b5cfbc46a Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 51.D7.09019.CFC5B625; Sat, 26 Oct 2013 08:11:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Sat, 26 Oct 2013 08:11:07 +0200 From: Christer Holmberg To: Andrew Allen , "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cE1yVFOeZTcSEqdPCNN7XweJJoF58BKgAAAXnGAABPnAIAAhMh4 Date: Sat, 26 Oct 2013 06:11:06 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4F7392@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_p5resuv9shytp50fyam5xkkr1382767863863emailandroidcom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6fmOwgg8u3+C3uz9vKaLFiwwFW i68/NrE5MHv8ff+ByWNWw1p2jyVLfjIFMEdx2aSk5mSWpRbp2yVwZTRN8Ss4YVDRfWM+SwPj Kc0uRk4OCQETifVvjjNC2GISF+6tZ+ti5OIQEjjKKLF00kF2CGcJo0RvwyamLkYODjYBC4nu f9ogcRGBJkaJF/fXsoF0CwskShzaP5EJxBYRSJL4f/YplO0msXXZbFYQm0VAVWL73FawbbxA 8T0f77FALOhilJh5cDJYEaeAp8T5A/fAhjICnfT91BqwQcwC4hK3nsxngjhVQGLJnvPMELao xMvH/1hBjmMWyJHY99AcYr6gxMmZT1gmMArPQtI9C6FqFpIqiBIdiQW7P7FB2NoSyxa+Zoax zxx4zIQsvoCRfRUjR3FqcVJuupHBJkZg3Bzc8ttiB+PlvzaHGKU5WJTEeT++dQ4SEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwMh2aUfprqaEaRuuO8Z+WaHUuEP31xUnn/eRMTxGB2Nc4uvi f9i8dFtjpXws8RCj8hH9npfPlkp87PebrbKGO9D+o6zUvqZv9+akL1r8fv/S5SvWh+w773KF 4Xwmf93aNOZSwXdNXy5v+a3NcS2+zfj6s9uZO7zjrLgf87uvVRZbqL+yb7JIwzQlluKMREMt 5qLiRAD2nzyNaQIAAA== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 06:11:16 -0000 --_000_p5resuv9shytp50fyam5xkkr1382767863863emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I wasn't suggesting that you could do everything with URI parameters - it w= as only a side note on how you could imdicate which method to use :) Regards, Christer Sent from my Sony Ericsson Xperia arc S Andrew Allen wrote: Christer It gets worse - how would you indicate support for extensions and event pac= kages using the URI mechanism? I think we need to keep with the idea that things are grouped together unde= r a single Feature-Caps header field. Andrew From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, October 25, 2013 04:04 PM Central Standard Time To: Paul Kyzivat ; Andrew Allen; SIPCORE Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators Hi, >> As a side note, you can also indicate a SIP method as a URI parameter: >> >> sip:transfer@example.com;method=3Drefer > > Yes. But *that* has its own semantics. It means that when you use that > URI in a request, the method should be REFER. You could repeat the address, with different method values in each. Yes, it WOULD be an ugly hack :) Regards, Christer --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_p5resuv9shytp50fyam5xkkr1382767863863emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi,=0A=
=0A=
I wasn't suggesting that you could do everything with URI parameters - it w=
as only a side note on how you could imdicate which method to use :)=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Andrew Allen <aallen@blackberry.com> wrote:=0A=
=0A=

Christer

It gets worse - how would you indicate support for extensions and event pac= kages using the URI mechanism?

I think we need to keep with the idea that things are grouped together unde= r a single Feature-Caps header field.

Andrew
 
From: Christer Holmberg [mailto:christer.holmberg@erics= son.com]
Sent: Friday, October 25, 2013 04:04 PM Central Standard Time
To: Paul Kyzivat <pkyzivat@alum.mit.edu>; Andrew Allen; SIPCOR= E <sipcore@ietf.org>
Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipc= ore-sip-tree-cap-indicators
 

Hi,

 

>> As a side note,= you can also indicate a SIP method as a URI parameter:
>>
>> sip:transfer@example.com;method=3Drefer
>
> Yes. But *that* has its own semantics. It means that when you use that=
> URI in a request, the method should be REFER.

 

You could repeat the add= ress, with different method values in each.

 

Yes, it WOULD be&nb= sp;an ugly hack :)

 

Regards,

 

Christer

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
--_000_p5resuv9shytp50fyam5xkkr1382767863863emailandroidcom_-- From dhanes@cisco.com Sat Oct 26 09:42:02 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC77A11E81AD for ; Sat, 26 Oct 2013 09:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odkzc5W-tQ9E for ; Sat, 26 Oct 2013 09:41:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D717E11E8107 for ; Sat, 26 Oct 2013 09:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1891; q=dns/txt; s=iport; t=1382805717; x=1384015317; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3c2+u78tBJqMsPIOaFASizUoCy9U0ld3EwJmmgJQPzQ=; b=RFBAlUtRcP+UszGaTN/ylR4jM537qmhsMoS0cGybDOv9svTkgk3q0XdX ymLQmQobE86Lyu9EgiOa14aDv5j8k3+TopmR2MNDHHMbuh2wHX/5nbqzg ZTg+bkyafML84EAIxjDCaE0pjPG1T0nCs52LX/wumd+H/W+hhm36MZNqs Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAHfwa1KtJV2a/2dsb2JhbABZDoJ5OFS+BEuBIBZ0giUBAQEDAQEBATc0CxIBCBgKFDcLJQIEAQ0FCBOHZgYNt3EEjhyBCDEHgx+BDQOqEYJnP4FxOQ X-IronPort-AV: E=Sophos;i="4.93,577,1378857600"; d="scan'208";a="276837782" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 26 Oct 2013 16:41:56 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9QGfuKO010781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 26 Oct 2013 16:41:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Sat, 26 Oct 2013 11:41:55 -0500 From: "David Hanes (dhanes)" To: "Gonzalo Salgueiro (gsalguei)" , Paul Kyzivat Thread-Topic: [sipcore] draft-johansson-sip-dual-stack Thread-Index: AQHOz2qzI4jONYz/JU+WCT5IOHuUfpoDA1eAgAALSQCAAqgKX4ABj9IA Date: Sat, 26 Oct 2013 16:41:55 +0000 Message-ID: In-Reply-To: <7C27864E-E549-44EE-B4DF-2A7263FA4530@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.117.39.206] Content-Type: text/plain; charset="us-ascii" Content-ID: <1D4487AFA1D3214FB89132018626176E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" , "ipv6@sipforum.org" Subject: Re: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 16:42:03 -0000 I've already provided my support for adoption of this work by SIPCORE. I'll reiterate here that not only do I support the work, but would be willing to review and offer feedback. Thanks, David On 10/25/13 1:50 PM, "Gonzalo Salgueiro (gsalguei)" wrote: > >> On Oct 23, 2013, at 4:17 PM, "Paul Kyzivat" >>wrote: >>=20 >>> On 10/23/13 3:36 PM, Olle E. Johansson wrote: >>>=20 >>> Personally I think it's the duty of the IETF to make sure that the >>>transition to IPv6 works smoothly. Without work on dual stack, the SIP >>>vendors will not dare delivering dual stack solutions and we'll stay on >>>IPv4-only VPNs. >>> We have proven that there are a lot of issues with dual stack networks >>>at SIPit tests. >>=20 >> I think so too. >> But the only resources the IETF has to work on this are the ones >>reading this mail. What we need to know is if there is a sufficient body >>of people willing, and sufficiently knowledgeable, to *contribute*. >>Minimally by reviewing and commenting on drafts. But we need people who >>will do more - provide text, implement, test. > >I should point out that this deficiency was initially uncovered through >interop and performance testing done by the SIP Forum (SIPit) and then >subsequently taken on as a work item by the SIP Forum IPv6 TG (copied >here). So, in addition to those who have offered their support and >willingness to contribute over the past few weeks, there are other >interested (and qualified) folks that could contribute to reviews, >implement, test, etc. > >Cheers,=20 > >Gonzalo >>=20 >> So we are looking for people who will promise to do those things. >>=20 >> Thanks, >> Paul >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From carl_klatsky@cable.comcast.com Mon Oct 28 06:18:42 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA2F11E8340 for ; Mon, 28 Oct 2013 06:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.931 X-Spam-Level: X-Spam-Status: No, score=-3.931 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trU73+8Nn+pN for ; Mon, 28 Oct 2013 06:18:37 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id BCA9411E8262 for ; Mon, 28 Oct 2013 06:17:25 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.101749533; Mon, 28 Oct 2013 07:17:21 -0600 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Mon, 28 Oct 2013 09:17:21 -0400 Received: from PACDCEXMB15.cable.comcast.com ([169.254.2.200]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Mon, 28 Oct 2013 09:17:21 -0400 From: "Klatsky, Carl" To: "'David Hanes (dhanes)'" , "'Gonzalo Salgueiro (gsalguei)'" , 'Paul Kyzivat' Thread-Topic: [sipcore] draft-johansson-sip-dual-stack Thread-Index: AQHOz2qzI4jONYz/JU+WCT5IOHuUfpoDA1eAgAALSQCAAqgKX4ABj9IAgALaXaA= Date: Mon, 28 Oct 2013 13:16:34 +0000 Message-ID: <6C15A6B88541034E912E94C2D8BC3E87E7FBF84F@PACDCEXMB15.cable.comcast.com> References: <7C27864E-E549-44EE-B4DF-2A7263FA4530@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.178] x-wiganss: 0100000001001Epacdcexhub05.cable.comcast.com ID0048<6C15A6B88541034E912E94C2D8BC3E87E7FBF84F@PACDCEXMB15.cable.comcast.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'sipcore@ietf.org'" , "'ipv6@sipforum.org'" Subject: Re: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 13:18:42 -0000 I support this work item also, and would be willing to review & offer feedb= ack as well. Regards, Carl Klatsky I've already provided my support for adoption of this work by SIPCORE. I'll reiterate here that not only do I support the work, but would be willi= ng to review and offer feedback. Thanks, David On 10/25/13 1:50 PM, "Gonzalo Salgueiro (gsalguei)" wrote: > >> On Oct 23, 2013, at 4:17 PM, "Paul Kyzivat" >>wrote: >>=20 >>> On 10/23/13 3:36 PM, Olle E. Johansson wrote: >>>=20 >>> Personally I think it's the duty of the IETF to make sure that the=20 >>>transition to IPv6 works smoothly. Without work on dual stack, the=20 >>>SIP vendors will not dare delivering dual stack solutions and we'll=20 >>>stay on IPv4-only VPNs. >>> We have proven that there are a lot of issues with dual stack=20 >>>networks at SIPit tests. >>=20 >> I think so too. >> But the only resources the IETF has to work on this are the ones=20 >>reading this mail. What we need to know is if there is a sufficient=20 >>body of people willing, and sufficiently knowledgeable, to *contribute*. >>Minimally by reviewing and commenting on drafts. But we need people=20 >>who will do more - provide text, implement, test. > >I should point out that this deficiency was initially uncovered through=20 >interop and performance testing done by the SIP Forum (SIPit) and then=20 >subsequently taken on as a work item by the SIP Forum IPv6 TG (copied=20 >here). So, in addition to those who have offered their support and=20 >willingness to contribute over the past few weeks, there are other=20 >interested (and qualified) folks that could contribute to reviews,=20 >implement, test, etc. > >Cheers, > >Gonzalo >>=20 >> So we are looking for people who will promise to do those things. >>=20 >> Thanks, >> Paul >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From aallen@blackberry.com Mon Oct 28 13:22:45 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32C811E81CE for ; Mon, 28 Oct 2013 13:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.071 X-Spam-Level: X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBqeO2meh4e3 for ; Mon, 28 Oct 2013 13:22:40 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 52B9C11E8214 for ; Mon, 28 Oct 2013 13:22:39 -0700 (PDT) Received: from xct103ads.rim.net ([10.67.111.44]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 28 Oct 2013 16:22:36 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.03.0123.003; Mon, 28 Oct 2013 15:22:35 -0500 From: Andrew Allen To: Paul Kyzivat , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUo+ZAiuycmUumaJncVjjxK5oKi8CQ Date: Mon, 28 Oct 2013 20:22:34 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> In-Reply-To: <526AD98E.5000907@alum.mit.edu> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 20:22:45 -0000 Paul In actual usage many feature capability indicators (FCIs) are being used to= communicate URIs. The ones that communicate URIs listed below are just fro= m one 3GPP 3GPP specification (and there are several other specifications t= hat define feature capability indicators) and many of these FCIs were defin= ed by the authors of RFC 6809. So I think it has been found to be necessary= to communicate URIs in FCIs. Usually these URIs are used as the Request-UR= I of a SIP request and the URI is hosted by the server that included the FC= I. If a UA indicates a URI hosted by it and a UA also indicates certain capabi= lities such as he supported SIP methods and SIP extensions I think you can = infer that the UA supports those methods and extensions and the UA can be c= ontacted at the URI. When contacting the UA at the indicated URI it seems = to me to be a reasonable assumption to make that the methods and extensions= also indicated are going to be supported. If the physical entity inserting the FCIs has different URIs that represent= logically different UAs (with different SIP methods and extensions support= ed) then the different logical UAs and their associated capabilities should= be indicated in different Feature-Caps header fields. List of FCIs from 3GPP TS 24.237 that have a URI as a value: ---------------------------- Table C.4-1: ABNF syntax of values of the g.3gpp.atcf feature-capability in= dicator g-3gpp-atcf-in-path =3D STN-SR STN-SR =3D "<" addr-spec ">" The feature-capability indicator is intended primarily for use in the follo= wing applications, protocols, services, or negotiation mechanisms: This fea= ture-capability indicator is used to indicate support of the ATCF. Examples of typical use: Indicating the presence and support of an ATCF on = the routing path of the SIP REGISTER request and SIP response to the SIP RE= GISTER request and providing the session transfer number allocated to this = ATCF. ---------------------------- ---------------------------- Table C.6-1: ABNF syntax of values of the g.3gpp.atcf-mgmt-uri feature-capa= bility indicator g-3gpp-atcf-mgmt-uri-in-path =3D "<" SIP-URI ">" String with an equality relationship. When used in a Feature-Caps header fi= eld, the value is string following the syntax as described in table C.6-1 f= or g-3gpp-atcf-mgmt-uri-in-path. The feature-capability indicator is intended primarily for use in the follo= wing applications, protocols, services, or negotiation mechanisms: This fea= ture-capability indicator is used to indicate the management URI of the ATC= F for receiving SIP requests where the ATCF performs the UAS role. ---------------------------- ---------------------------- Table C.8-1: ABNF syntax of values of the g.3gpp.atcf-path feature-capabili= ty indicator g-3gpp-atcf-path =3D "<" SIP-URI ">" Values appropriate for use with this feature-capability indicator: = String with an equality relationship. When used in a Feature-Caps header fi= eld, the value is a SIP URI of ATCF, the ATCF URI for terminating requests,= identifying the registration path following the syntax as described in tab= le C.8-1 for g-3gpp-atcf-path. ---------------------------- ---------------------------- Table C.9A-1: ABNF syntax of string values of the g.3gpp.cs2ps-srvcc featur= e-capability indicator g.3gpp.cs2ps-srvcc-value =3D STI-rSR STI-rSR =3D "<" addr-spec ">" When the value is string, the value contains the session transfer identifie= r for CS to PS SRVCC and follows the syntax as described in table C.9A-1 fo= r g.3gpp.cs2ps-srvcc-value. ---------------------------- ---------------------------- Table C.17-1: ABNF syntax of values of the g.3gpp.dynamic-stn feature-capab= ility indicator g-3gpp-dynamic-stn =3D TEL-URI TEL-URI =3D "" ; global-number-digits as spec= ified in IETF RFC 3966[79] String with an equality relationship. When used in a Feature-Caps header fi= eld in SIP INVITE request or SIP response, the value is string containing t= he digit string in tel URI format of the dynamic STN to be used to establis= h a CS call in order to transfer the session to the CS domain following the= syntax as described in table C.17-1 for g-3gpp-dynamic-stn.The feature-cap= ability indicator is intended primarily for use in the following applicatio= ns, protocols, services, or negotiation mechanisms: This feature-capability= indicator is used to indicate support to transfer the session to the CS do= main using the digit string of the dynamic STN. ---------------------------- Andrew -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] = Sent: Friday, October 25, 2013 4:50 PM To: Andrew Allen; Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators On 10/25/13 4:38 PM, Andrew Allen wrote: > > In my view the basic premise of Feature-Caps is that an entity on the rou= te is indicating that it supports a particular capability. Indicating suppo= rt for features by other entities is rather problematic. I suppose a servic= e proxy on the route could also indicate features supported by other physic= al servers that it has responsibility for that are not hosted physically by= it. It was also a basic premise of feature-caps that it didn't specify the addr= ess of the thing reporting the capabilities. The explanation at the time was that it wasn't necessary - that it was only= necessary that there was something on the path that had those capabilities. > I agree with Christer that if an entity needs to support multiple sets of= features that do not all apply to the same server then it should do so in = separate Feature-Caps header fields with only the features that are all hos= ted by the same entity being included in the same Feature-Caps header field. > > I think entities advertising features that they are not responsible for a= nd have nothing to do with is bogus. I agree with that. Then what does it mean for something on the path to insert an FCI containin= g a URI? That seems ok as long as you don't infer that other FCIs with it a= pply to the thing with that URI. Thanks, Paul > Andrew > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = > Behalf Of Paul Kyzivat > Sent: Friday, October 25, 2013 4:28 PM > To: Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] New sipcore draft submission = > draft-allen-sipcore-sip-tree-cap-indicators > > Inline. > > On 10/25/13 2:57 PM, Christer Holmberg wrote: >> Hi, >> >> .... >> >>>> /Example:/ >>>> >>>> I support the find-Paul feature, and I insert a FCI: >>>> >>>> Feature-Caps: *, +g.find-paul=3D"sip:pkyzivat@alum.mit.edu" >>>> >>>> Now, in this case the address does NOT point to my entity, but to = >>>> Paul's entity. My entity supports a feature, which provides Paul's add= ress. >>>> >>>> So, if the FCI says: >>>> >>>> Feature-Caps: *, >>>> +g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.methods=3D"invite" >>>> >>>> ...it doesn't automatically mean that I can contact Paul using INVITE. >>>> By default it means that MY entity supports the INVITE method - = >>>> which from the find-paul feature perspective is useless information. >>>> >>>> So, in the FCI specification for +g.find-paul, I would have to = >>>> explictily describe how the FCI works in conjunction with other = >>>> FCIs. I would have to explicitly say that, when used together >>>> +sip.methods, the >>>> +sip.methods indicates which SIP methods I can use to contact Paul >>>> (using the address provide in the +g.find-paul FCI). >>> >>> So far I agree. >>> >>> But suppose there is also a find-christer FCI. So we have: >>> >>> Feature-Caps: * >>> ;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu" >>> ;+g.find-paul=3D"sip:christer.holmberg@ericsson.com" >>> ;+sip.methods=3D"invite" >>> >>> And both find-paul and find-christer want to define the use of other = >>> FCIs. Then things start to become ambiguous. >>> >>> Should the description of find-paul specify what other FCIs "pertain" >>> to it? Or should the description of sip.methods specify what FCI(s) = >>> provide the address at which it applies? Or both? What if paul and = >>> christer support different methods? >> >> In that case you would need to have two different Feature-Caps header >> fields: >> >> Feature-Caps: >> *;+g.find-paul=3D"sip:pkyzivat@alum.mit.edu";+sip.methods=3D"invite" >> Feature-Caps: >> *;+g.find-paul=3D"sip:christer.holmberg@ericsson.com";+sip.methods=3D"me= ssage" > > That seemingly solves the problem, but if the same entity inserts them bo= th then its a questionable use of Feature-caps isn't it? > >> In your example you had two instances of the same FCI (is that even = >> allowed?), > > I did? find-paul and find-christer are two different FCIs. > (But that sort of naming will be troublesome for the registry and for = > the expert who has to approve entries in it.:-) > > but there could also have been a case with two different >> FCIs, both using +sip.methods, in which case you may have to put them = >> into separate Feature-Caps header fields. >> >> These things would have to be clearly specified. > > Very definitely. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> >>> Section 5.3.8 in RFC 6809 also says: >>> >>> "If there is additional information about the feature-capability >>> indicator, it is recommended to describe such information. It= can >>> include, for example, *names of related feature-capability = >>> indicators*." >>> >>> So, in your case, I think the +g.3gpp.see_trans FCI specifiction = >>> would have to specify how the FCI is used in conjuntion with other = >>> FCIs, including the +sip.method FCI. >>> >>> Something like: "When the session transfer request is sent to the = >>> address indicated by the FCI value, the +sip.method FCI indicates = >>> which SIP methods can be used." >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> *From*: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> *Sent*: Friday, October 25, 2013 12:01 PM Central Standard Time >>> *To*: Andrew Allen; Paul Kyzivat ; Gonzalo = >>> Camarillo >>> *Cc*: rlb@ipv.sx ; adam@nostrum.com ; = >>> mary.ietf.barnes@gmail.com >>> *Subject*: RE: New sipcore draft submission = >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> Hi, >>> >>>> I think we can have an FCI >>> >>>> >>> >>>> Feature-Caps: *;+g.3ggp.sess_trans=3D"sip:foo@example.com;gr" >>> >>>> >>> >>>> Indicating that the entity supports 3GPP session transfer and the = >>>> address where you send the session transfer request is = >>>> sip:foo@example.com;gr >>> >>> Correct. The FCI itself indicates support of session transfer = >>> feature, and the FCI value indicates the address associatd with the fea= ture. >>> >>>> Also if I have: >>> >>>> >>> >>>> Feature-Caps: *;+g.3ggp.sess_trans=3Dsip:foo@example.com;gr; >>>> +sip.extensions=3D"replaces, tdialog"; >>> +sip.methods=3D"invite, refer, bye, options, update, prack" >>> >>>> >>> >>>> This means the entity supports 3GPP session transfer and the address w= here you send the session transfer request is sip:foo@example.com;gr ... >>> >>> Correct. >>> >>>> ...supports the replaces and target dialog extensions and supports the= following methods - invite, refer, bye, options, update, prack. >>> >>> Technically, what it means is that there is *AN* entity which = >>> supports the features listed above, and the address is where you are = >>> to send the session transfer request in order to trigger the 3GPP = >>> session transfer feature. >>> >>> Regards, >>> >>> Christer >>> >>> *From:*Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> *Sent:* Friday, October 25, 2013 10:25 AM >>> *To:* Paul Kyzivat; Andrew Allen; Gonzalo Camarillo >>> *Cc:* rlb@ipv.sx; adam@nostrum.com; mary.ietf.barnes@gmail.com >>> *Subject:* RE: New sipcore draft submission = >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> Hi, >>> >>> As Paul said, if one needs to provide address information associated = >>> with a FCI, the address information cannot be a FCI of its own. It = >>> needs to be a value of the FCI for which it is associated. >>> >>> Something like: >>> >>> Feature-Caps: *;+audio=3D"sip:foo@example.com" >>> >>> (Also note that the "+" sign is mandatory for all FCIs - no matter = >>> which registry tree they belong to) >>> >>> Regards, >>> >>> Christer >>> >>> -------------------------------------------------------------------- >>> - >>> --- >>> >>> *From:*Paul Kyzivat [pkyzivat@alum.mit.edu] >>> *Sent:* Friday, 25 October 2013 5:06 PM >>> *To:* Andrew Allen; Gonzalo Camarillo >>> *Cc:* rlb@ipv.sx ; adam@nostrum.com = >>> ; Christer Holmberg; = >>> mary.ietf.barnes@gmail.com >>> *Subject:* Re: New sipcore draft submission = >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> Andrew, >>> >>> (I see this is still on the private thread. I'll reply here, but = >>> this exchange should probably be reposted to the sipcore list as = >>> part of the public discussion of the draft.) >>> >>> On 10/24/13 10:41 PM, Andrew Allen wrote: >>>> >>>> Paul >>>> >>>> I am happy to do a revision with more details on the semantics of the = capability indicators. However I don't think it should be held to a very mu= ch higher bar than the details in RFC 3840 and the other media feature tag = RFCs regarding the meaning of thosetags. >>> >>> Keep in mind that the driving force for the definition of feature = >>> tags in 3840 was in support of callerprefs (3841). So the context = >>> for the use of feature tags was that they would be placed on = >>> Contacts in REGISTER requests. So you can interpret the definitions = >>> in that >>> context: that a request sent to an AOR using callerprefs can affect = >>> the choice of which device the request goes to according to the = >>> capabilities it wants. In that context audio, video, isfocus all make s= ense. >>> >>> Their use on Contacts in dialogs was derivative to that: because = >>> callerpref support is optional, there is no guarantee that the = >>> device you reach via callerprefs will have the capabilities you request= ed. >>> So the values in the contact help confirm what you got. >>> >>> Of course they have since been used other ways. And the descriptions = >>> of them don't necessarily reflect that. IMO that is a defect due to = >>> the evolution of use. >>> >>> I'm looking for the same sort of context for use with the feature-caps. >>> >>> In private discussion you indicated to me that you expected the = >>> feature caps to be grouped - with one of them giving the URI of the = >>> device that the other tags apply to. I guess this would end up looking = something like: >>> >>> Feature-Caps: *;g.uri=3D"sip:foo@example.com";audio >>> Feature-Caps: *;g.uri=3D"sip:bar@example.com";audio;video;isfocus >>> Feature-Caps: *;g.uri=3D"sip:baz@example.com";text >>> >>> (I'm making up g.uri for the example.) >>> >>> And then presumably somebody on the signaling path will "shop" in = >>> the feature caps for the capabilities it wants, and then send a = >>> request to that URI, with the expectation that the UA responding = >>> will have those capabilities. >>> >>>> The semantics should be no different than those of the corresponding = existing media feature tag if it is present in the Contact header. >>> >>> Note that 6809 says: >>> >>> When a SIP entity receives a SIP request, or response, that conta= ins >>> one or more Feature-Caps header fields, the feature-capability >>> indicators in the header field inform the entity about the featur= es >>> and capabilities supported by entities in the SIP message signali= ng >>> path. The procedure by which features and capabilities are invok= ed >>> are outside the scope of this specification and MUST be described= by >>> individual feature-capability indicator specifications. >>> >>> A Feature-Caps header field value cannot convey the address of the >>> SIP entity that inserted the Feature-Caps header field. If >>> additional data about a supported feature needs to be conveyed, s= uch >>> as the address of the SIP entity that indicated support of the >>> feature, then the feature definition needs to define a way to con= vey >>> that information as a value of the associated feature-capability >>> indicator. >>> >>> This was discussed at length while that RFC was under consideration. >>> Yet the definitions of the tags in *this* draft don't specify that. >>> >>>> The registration templates currently reference the RFC 3840 and the ot= her RFCs that define the other media feature tags that correspond to these = feature capability indicators. >>> >>> And those definitions were written to be understood in the context = >>> of 3840/3841. They make sense in that context, but not in *this* contex= t. >>> >>> Thanks, >>> Paul >>> >>>> But if more explicit detail is required then I can add some more text = or alternatively remove the less important ones if they are going to becom= e rat holes. The ones I regard as really important and urgent are sip.metho= ds, sip.extensions and sip.events the meaning of which I think should be = quite clear. >>>> >>>> Andrew >>>> >>>> ----- Original Message ----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Thursday, October 24, 2013 04:44 PM Central Standard Time >>>> To: Andrew Allen;Gonzalo.Camarillo@ericsson.com >>>> >>> >> > >>>> Cc:rlb@ipv.sx >; >>> adam@nostrum.com >> >; christer.holmberg@ericsson.com = >>> >>> >> >; mary.ietf.barnes@gmail.com = >>> >> >; Paul Kyzivat = >>> > >>>> Subject: Re: New sipcore draft submission = >>>> draft-allen-sipcore-sip-tree-cap-indicators >>>> >>>> On 10/24/13 4:07 PM, Andrew Allen wrote: >>>>> >>>>> Paul >>>>> >>>>> Ok >>>>> >>>>> So we are basically where I thought we were at when I submitted the d= raft. >>>>> >>>>> Maybe you, Adam, Gonzalo, Richard, Christer and I (plus anyone else w= ho indicates interest) can have some offline discussion in Vancouver on whe= ther and how to progress this. >>>> >>>> As I indicated again on the sipcore list, I found the that the = >>>> draft didn't explain nearly enough to allow meaningful use of these. >>>> I know you replied, and I will continue the conversation there. >>>> But I will be opposed to these until and unless the draft (and = >>>> notably the descriptions of the tags) are clear about how one could = >>>> figure out what can do in the presence of the tags that one = >>>> couldn't do without them. AND, that the behavior that suggests = >>>> doesn't "break" sip. (E.g., by advocating a new and incompatible = >>>> way to do >>>> something.) >>>> >>>> We can continue this on the sipcore list. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Andrew >>>>> >>>>> ----- Original Message ----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Sent: Thursday, October 24, 2013 02:54 PM Central Standard Time >>>>> To: Andrew Allen; Gonzalo Camarillo = >>>>> >>>> > >>>>> Cc: Richard Barnes (rlb@ipv.sx ) >>>> >; Adam >>> Roach (adam@nostrum.com ) >> >; Christer Holmberg = >>> (christer.holmberg@ericsson.com >>> ) >>> >> >; Mary Barnes = >>> (mary.ietf.barnes@gmail.com ) < = >>> mary.ietf.barnes@gmail.com > >>>>> Subject: Re: New sipcore draft submission = >>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>> >>>>> On 10/24/13 2:17 PM, Andrew Allen wrote: >>>>>> Paul >>>>>> >>>>>> That is fine. Although Mary in her reply to me seemed to indicate ma= ybe there was a possibility to use some of the DISPATCH spare time for a SI= PCORE session for this. Is that a possibility? >>>>>> >>>>>> I already replied to your post >>>>> >>>>> I discussed that with Adam. We decided we can't set a precedent to = >>>>> spin up a session to discuss a draft that hasn't had substantial >>>>> (any) list discussion. >>>>> >>>>> But list discussion is always welcome. >>>>> >>>>> Sorry, >>>>> Paul >>>>> >>>>>> Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>> Sent: Thursday, October 24, 2013 1:31 PM >>>>>> To: Andrew Allen; Gonzalo Camarillo >>>>>> Cc: Richard Barnes (rlb@ipv.sx ); Adam Roach = >>>>>> (adam@nostrum.com >>> ); Christer Holmberg = >>> (christer.holmberg@ericsson.com >>> ) >>>>>> Subject: Re: New sipcore draft submission = >>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>> >>>>>> Andrew, >>>>>> >>>>>> I spoke with Mary about it, and we concluded that dispatch isn't rig= ht for this. (In addition to being clearly sipcore, it didn't meet the dead= line for dispatch.) I was wrong to encourage you that way. >>>>>> >>>>>> So no official live discussion in Vancouver. (But informal = >>>>>> discussion >>>>>> fine.) >>>>>> >>>>>> I'll resend my private comments to the sipcore list to kickstart som= e discussion there. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 10/24/13 1:01 PM, Andrew Allen wrote: >>>>>>> I just emailed Mary asking for agenda time. Should I cancel that re= quest? >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>>>> Sent: Thursday, October 24, 2013 1:00 PM >>>>>>> To: Paul Kyzivat >>>>>>> Cc: Andrew Allen; Richard Barnes (rlb@ipv.sx = >>>>>>> ); Adam Roach (adam@nostrum.com = >>>>>>> ); Christer Holmberg >>> (christer.holmberg@ericsson.com >>> ) >>>>>>> Subject: Re: New sipcore draft submission = >>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>> >>>>>>> Hi Paul, >>>>>>> >>>>>>> given that you think this belongs to SIPCORE, I do not see the need= to run it through DISPATCH. Please, start technical discussions on the dra= ft on the SIPCORE list. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Gonzalo >>>>>>> >>>>>>> On 22/10/2013 9:11 PM, Paul Kyzivat wrote: >>>>>>>> On 10/22/13 1:00 PM, Andrew Allen wrote: >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> Thanks for reviewing the draft already and giving me early feedba= ck. >>>>>>>>> >>>>>>>>> My responses below inline (prepended with [AA). >>>>>>>>> >>>>>>>>> Can I ask the ADs to determine ASAP if this needs to go to = >>>>>>>>> DISPATCH first or not. As outlined below my view is that it is = >>>>>>>>> unnecessary for every little thing to go to DISPATCH as this = >>>>>>>>> just creates additional delay and overhead. If it is to be = >>>>>>>>> discussed in DISPATCH then I definitely would want agenda time at= IETF#88 for this. >>>>>>>> >>>>>>>> Having now seen Andrew's responses to my initial questions, I = >>>>>>>> think this >>>>>>>> *needs* to be carefully considered by sipcore. IMO this has the = >>>>>>>> potential to create a dialect of sip that is incompatible with = >>>>>>>> normal usage. (Maybe IMS has already done that. But this will = >>>>>>>> make it >>>>>>>> worse.) >>>>>>>> >>>>>>>> But if there is a desire to discuss it publicly in Vancouver = >>>>>>>> then dispatch is the opportunity and so some discussion on the = >>>>>>>> dispatch list in advance of that would be appropriate. >>>>>>>> >>>>>>>> I'll defer to the ADs on this. >>>>>>>> >>>>>>>> More inline. >>>>>>>> >>>>>>>>> Andrew >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>>>>>> Sent: Tuesday, October 22, 2013 10:33 AM >>>>>>>>> To: Andrew Allen; Richard Barnes (rlb@ipv.sx = >>>>>>>>> ); Gonzalo Camarillo = >>>>>>>>> (Gonzalo.Camarillo@ericsson.com = >>>>>>>>> ); >>> Adam Roach (adam@nostrum.com ) >>>>>>>>> Subject: Re: New sipcore draft submission = >>>>>>>>> draft-allen-sipcore-sip-tree-cap-indicators >>>>>>>>> >>>>>>>>> Andrew, >>>>>>>>> >>>>>>>>> On a legalistic note, its questionable to me whether this kind = >>>>>>>>> of action falls within the scope of sipcore. OTOH, among = >>>>>>>>> existing wgs, sipcore is probably the best suited to discuss = >>>>>>>>> the proposal. We could take it to DISPATCH. I think DISPATCH = >>>>>>>>> has extra time in its agenda for Vancouver, so that might be = >>>>>>>>> one option for you. But then I don't know where dispatch would = >>>>>>>>> dispatch it. It may be that AD sponsored is the best way to go. >>>>>>>>> >>>>>>>>> [AA] It seemed to me that sipcore was the right place. This = >>>>>>>>> draft registers feature-capability indicators in a registry = >>>>>>>>> that was created by a sipcore RFC (RFC 6809). You could in my = >>>>>>>>> view make an argument that this should even have been done as par= t of RFC 6809. >>>>>>>> >>>>>>>> If this was just a matter of registering some new feature caps = >>>>>>>> that were not controversial, then I don't think sipcore needs to b= e involved. >>>>>>>> >>>>>>>> But as I mentioned above, I do consider these controversial. >>>>>>>> >>>>>>>>> Discussing it now on the dispatch list would be a good start = >>>>>>>>> toward discussing it at the dispatch session. >>>>>>>>> >>>>>>>>> [AA] Can I ask the ADs to determine if this needs to go to = >>>>>>>>> DISPATCH first or not. My view is that it is unnecessary for = >>>>>>>>> every little thing to go to DISPATCH as this just creates additio= nal delay and overhead. >>>>>>>>> This just registers some indicators in an existing IANA = >>>>>>>>> registry and is not (or should not be IMHO) a major project. >>>>>>>> >>>>>>>> To me this is a matter of whether you want to be opportunistic. >>>>>>>> If this went to dispatch I would now recommend that it be = >>>>>>>> dispatched to sipcore. So its a matter of whether you want to = >>>>>>>> talk about it in the dispatch meeting. >>>>>>>> >>>>>>>>> Regarding substance, this draft troubles me. It takes = >>>>>>>>> feature-caps in exactly the direction that I found most = >>>>>>>>> concerning about the mechanism in the first place. >>>>>>>>> >>>>>>>>> Your draft partitions the existing media feature tags into two = >>>>>>>>> sets >>>>>>>>> - those that would be useful as feature-capability-indicators, = >>>>>>>>> and those that aren't. But I see no explanation of the = >>>>>>>>> criteria used to make this distinction, nor can I think of one. >>>>>>>>> >>>>>>>>> [AA] I based this decision on the following criteria: If a = >>>>>>>>> feature tag was potentially at all useful for an intermediary = >>>>>>>>> to indicate it then include it in the registry. The ones not = >>>>>>>>> included are either directly associated with the user = >>>>>>>>> (intermediaries are not directly associated with the user) or = >>>>>>>>> would only ever have one value (e.g automata). I am not sure = >>>>>>>>> that every feature-capability indicator proposed to be = >>>>>>>>> registered is actually useful but then I don't think every = >>>>>>>>> media feature tag registered by RFC 3840 is either (I doubt = >>>>>>>>> very much if there are implementation using the = >>>>>>>>> sip.application or sip.control feature tags). I don't think = >>>>>>>>> RFC 3840 goes into a lot of details justifying of ever = >>>>>>>>> registered media feature tag and specifying the details of how = >>>>>>>>> they would be used either. I am willing to remove any feature-ca= pability indicators that are controversial except that I think we definitel= y need sip.extensions, sip.methods and sip.events. >>>>>>>>> There is a significant overhead to writing an >>>>>>>> d progressing internet drafts so my view is lets register all = >>>>>>>> that might be remotely useful in the same document. >>>>>>>> >>>>>>>> The judgement of "useful" is reasonable. But I still can't = >>>>>>>> discern what the use is from the iana registration descriptions. >>>>>>>> >>>>>>>>> For the ones that you have requested feature capability = >>>>>>>>> indicators, I cannot figure out what using them would mean. = >>>>>>>>> For example, when I see isFocus on a Contact header I know I = >>>>>>>>> am in a conference, and that I can subscribe to the conference = >>>>>>>>> event package at the contact URI. If I see isFocus in a Feature-C= aps header, what does it mean? >>>>>>>>> What can I do once I know this? >>>>>>>>> >>>>>>>>> Section 5.14 of this draft says: >>>>>>>>> >>>>>>>>> This Feature-capability indicator indicates that the= intermediary >>>>>>>>> is a conference server, also known as a focus, and i= s capable of >>>>>>>>> mixing together the media for all calls to the same = URI. >>>>>>>>> ... >>>>>>>>> Examples of typical use: A conference bridge = >>>>>>>>> indicating that it >>>>>>>>> is a conference bridge and is capable of = >>>>>>>>> acting as a conference >>>>>>>>> focus for this session. >>>>>>>>> >>>>>>>>> [AA] the presence of isfocus in a Feature-Caps header field = >>>>>>>>> means that a UA can initiate a conference by sending a REFER = >>>>>>>>> request to the intermediary to invite another user and create = >>>>>>>>> a multi user conference from the 1-1 session. >>>>>>>>> >>>>>>>>> Note that Feature-Caps doesn't indicate which entity has this = >>>>>>>>> capability, only that something does. And since this would = >>>>>>>>> presumably only be used if it wasn't the UAC of the request, = >>>>>>>>> sending a subscribe to the contact address of the UAC wouldn't ma= ke sense. >>>>>>>>> >>>>>>>>> [AA] Yes the GRUU of the intermediary would be needed but I = >>>>>>>>> consider this application specific and so this would be = >>>>>>>>> included in a feature tag registered in the global tree as = >>>>>>>>> stated in the draft "RFC 6809 [1] provides that addresses of = >>>>>>>>> intermediaries can be communicated as a value of an associated = >>>>>>>>> feature-capability indicator so it would be appropriate to = >>>>>>>>> define feature capability indicators as part of the global = >>>>>>>>> tree to communicate the GRUU of the intermediary and hence = >>>>>>>>> this is outside the scope of this document." - RFC 6809 = >>>>>>>>> states " If additional data about a supported feature needs to = >>>>>>>>> be conveyed, such as the address of the SIP entity that = >>>>>>>>> indicated support of the feature, then the feature definition = >>>>>>>>> needs to define a way to convey that information as a value of = >>>>>>>>> the associated feature-capability indicator." However I think = >>>>>>>>> the SIP specific capability indicators such as methods, = >>>>>>>>> extensions and events should appropriately be registered in = >>>>>>>>> the SIP tree not as proprietary indicator >>>>>>>> s in the global tree. >>>>>>>> >>>>>>>> So you have defined a sip tree feature tag that is only useful = >>>>>>>> in conjunction with another feature tag from the global tree. >>>>>>>> And the description of this feature tag doesn't even mention that. >>>>>>>> >>>>>>>> And this all implies a completely non-standard call model - = >>>>>>>> doing conferencing in a way inconsistent with RFC 4579. >>>>>>>> >>>>>>>> ISTM that if 4579 doesn't work for you then you should be back = >>>>>>>> proposing extensions/revisions to it. >>>>>>>> >>>>>>>>> If there is a conference bridge in the signaling path, then I = >>>>>>>>> would expect it to be the UAC. >>>>>>>>> >>>>>>>>> [AA] Although a "standard" way to invoke a conference is to = >>>>>>>>> send a REFER to the other UAs to invite them to the conference = >>>>>>>>> focus, in many deployments a scenario exists where a call = >>>>>>>>> involves an IP-PBX or Telephony Application Server (TAS) that = >>>>>>>>> can act as a focus for the conference. A participant of a call = >>>>>>>>> can then create a conference by sending a REFER request in = >>>>>>>>> dialog to the IP-PBX or TAS to use 3PCC to Invite other users to = a conference. Reasons for this are 1. >>>>>>>>> Not all UAs support REFER, >>>>>>>> >>>>>>>> So you are saying the intermediary isn't a focus (its a B2BUA), = >>>>>>>> but it *could become* a focus. >>>>>>>> >>>>>>>> The concept that a dialog may contain intermediaries that can = >>>>>>>> be addressed to do stuff is not part of any sip standard that I = >>>>>>>> am aware of. I don't care too much as long as the "stuff" is = >>>>>>>> application stuff that is outside the scope of sip. But when it = >>>>>>>> is alternative ways to do stuff that sip supports, then I get upse= t. >>>>>>>> >>>>>>>>> 2. Many SBCs reject REFER requests going outside domains = >>>>>>>>> because of the potential for charging fraud (referring to a = >>>>>>>>> premium rate number >>>>>>>>> etc) 3. A User receiving a REFER and then using an INVITE to = >>>>>>>>> join the conference may be charged for initiating the call = >>>>>>>>> when the scenario is that the initiator of the conference should = be charged. >>>>>>>>> 4. No need to obtain and distribute conference URIs. >>>>>>>>> Problem is how to achieve the same behavior without dialog = >>>>>>>>> reuse which has been deprecated by RFC 6665? >>>>>>>> >>>>>>>> Then maybe the problem needs to be brought up, and a standard = >>>>>>>> solution proposed, rather than simply enabling a proprietary mecha= nism. >>>>>>>> >>>>>>>>> As another example, consider section 5.1: >>>>>>>>> >>>>>>>>> Descrition: >>>>>>>>> This Feature-capability indicator indicates that the= intermediary >>>>>>>>> supports audio as a streaming media type. >>>>>>>>> ... >>>>>>>>> Examples of typical use: An IP PBX indicating tha= t it is >>>>>>>>> capable of accepting and initiating sessions with= audio as a >>>>>>>>> streaming media type. >>>>>>>>> >>>>>>>>> This definition *implies* an assumption about the working = >>>>>>>>> environment >>>>>>>>> - one that AFAIK is new. It implies that you need to know that = >>>>>>>>> intermediaries support a media type before you can use it. >>>>>>>>> Would it be bad if there were no intermediaries, and so none indi= cated this? >>>>>>>>> What if some intermediary *did* indicate support, but some = >>>>>>>>> other doesn't, but doesn't indicate that it doesn't? >>>>>>>>> >>>>>>>>> Bottom line: how would the presence or absence of this feature = >>>>>>>>> tag affect subsequent usage? >>>>>>>>> >>>>>>>>> [AA] The absence of the streaming types does not indicate that = >>>>>>>>> the intermediary does not support the media type and SDP offer = >>>>>>>>> answer will ultimately determine what can or cannot be used if = >>>>>>>>> another session is initiated involving the intermediary. >>>>>>>>> However the presence of the media type in a Feature-caps = >>>>>>>>> header field does explictly confirm that the intermediary does = >>>>>>>>> support the media type and in the scenario where a UA has a = >>>>>>>>> choice of multiple intermediaries it could use for a = >>>>>>>>> conference it might choose to use the one that explicitly indicat= es it supports the media types the UA wants to use. >>>>>>>> >>>>>>>> So the UA will be able to discover that *some* intermediary = >>>>>>>> supports media it is interested in. And it can tell that *some* = >>>>>>>> intermediary says it is a focus. It doesn't know if they are the s= ame intermediary. >>>>>>>> >>>>>>>> And then via some other feature tag it obtains the URI of = >>>>>>>> *some* intermediary on the signaling path. Or maybe it gets = >>>>>>>> more than one of these. >>>>>>>> >>>>>>>> It then makes a leap of faith and conflates all those things, = >>>>>>>> to determine that the URI identifies a focus that supports this me= dia type. >>>>>>>> >>>>>>>> Even then, exactly what does that mean? It may or may not mean = >>>>>>>> that it supports mixing that media type in a conference. >>>>>>>> >>>>>>>>> As I stated already I don't care that much about these = >>>>>>>>> streaming media types. >>>>>>>> >>>>>>>>> I could go on, but this is enough for now. >>>>>>>>> >>>>>>>>> [AA] My motivation for this is that currently 3GPP are = >>>>>>>>> updating their specifications to use RFC 6665 instead of RFC 3265. >>>>>>>> >>>>>>>>> 3GPP has a lot of dialog reuse with SUBSCRIBE and REFER with = >>>>>>>>> intermediaries accepting the REFER or SUBSCRIBE request rather = >>>>>>>>> than forwarding it all the way to the remote UA. >>>>>>>> >>>>>>>> And 6665 deprecates dial reuse in most of those cases. >>>>>>>> Without dialog reuse, the intermediaries don't get an = >>>>>>>> opportunity to intercept those. >>>>>>>> >>>>>>>>> In order to know that an intermediary supports the target = >>>>>>>>> dialog mechanism needed for a REFER request sent outside the = >>>>>>>>> dialog to work we need sip.extensions as a feature-capability = >>>>>>>>> indicator. In order to know that the needed event package is = >>>>>>>>> supported by the intermediary so we can SUBSCROBE outside the = >>>>>>>>> dialog to an intermediary we need sip.events as a feature-capabil= ity indicator. >>>>>>>> >>>>>>>> Then I think you should be back here with a problem statement = >>>>>>>> and a request for how to get sip to solve it. >>>>>>>> >>>>>>>> And you should touch base with Christer on this. He may have a = >>>>>>>> different opinion on the relevance of feature-caps as a solution. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> On 10/22/13 3:44 AM, Andrew Allen wrote: >>>>>>>>>> Adam, Paul, Richard, Gonzalo >>>>>>>>>> >>>>>>>>>> I have submitted a new draft to sipcore to register a number = >>>>>>>>>> of feature capability indicators in the SIP tree (based upon = >>>>>>>>>> some of the existing SIP media feature tags). The draft can be f= ound at: >>>>>>>>>> >>>>>>>>>> http://www.ietf.org/id/draft-allen-sipcore-sip-tree-cap-indicato= rs-00. >>>>>>>>>> txt >>>>>>>>>> >>>>>>>>>> Since there will not be a sipcore session at IETF#88 can we = >>>>>>>>>> have an offline discussion on how to progress this draft = >>>>>>>>>> (which hopefully is fairly straightforward as it just = >>>>>>>>>> registers feature capabilities indicators with IANA). I = >>>>>>>>>> wouldn't want to have to wait until March next year for a decisi= on on progressing this. >>>>>>>>>> >>>>>>>>>> Andrew >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>> - >>>>>>>>>> ----- >>>>>>>>>> - >>>>>>>>>> - This transmission (including any attachments) may contain = >>>>>>>>>> confidential information, privileged material (including = >>>>>>>>>> material protected by the solicitor-client or other = >>>>>>>>>> applicable privileges), or constitute non-public information. = >>>>>>>>>> Any use of this information by anyone other than the intended = >>>>>>>>>> recipient is prohibited. If you have received this = >>>>>>>>>> transmission in error, please immediately reply to the sender = >>>>>>>>>> and delete this information from your system. Use, = >>>>>>>>>> dissemination, distribution, or reproduction of this transmissio= n by unintended recipients is not authorized and may be unlawful. >>>>>>>>> >>>>>>>>> -------------------------------------------------------------- >>>>>>>>> - >>>>>>>>> ----- >>>>>>>>> - This transmission (including any attachments) may contain = >>>>>>>>> confidential information, privileged material (including = >>>>>>>>> material protected by the solicitor-client or other applicable = >>>>>>>>> privileges), or constitute non-public information. Any use of = >>>>>>>>> this information by anyone other than the intended recipient = >>>>>>>>> is prohibited. If you have received this transmission in = >>>>>>>>> error, please immediately reply to the sender and delete this = >>>>>>>>> information from your system. Use, dissemination, = >>>>>>>>> distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> - >>>>>>> ---- This transmission (including any attachments) may contain = >>>>>>> confidential information, privileged material (including = >>>>>>> material protected by the solicitor-client or other applicable = >>>>>>> privileges), or constitute non-public information. Any use of = >>>>>>> this informationby anyone other than the intended recipient is = >>>>>>> prohibited. If you have >>> received this transmission in error, please immediately reply to the = >>> sender and delete this information from your system. Use, = >>> dissemination, distribution, or reproduction of this transmission by = >>> unintended recipients is not authorized and may be unlawful. >>>>>>> >>>>>>> >>>>>> >>>>>> ----------------------------------------------------------------- >>>>>> - >>>>>> --- This transmission (including any attachments) may contain = >>>>>> confidential information, privileged material (including material = >>>>>> protected by the solicitor-client or other applicable = >>>>>> privileges), or constitute non-public information. Any use of = >>>>>> this informationby anyone other than the intended recipient is = >>>>>> prohibited. If you have >>> received this transmission in error, please immediately reply to the = >>> sender and delete this information from your system. Use, = >>> dissemination, distribution, or reproduction of this transmission by = >>> unintended recipients is not authorized and may be unlawful. >>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> -- This transmission (including any attachments) may contain = >>>>> confidential information, privileged material (including material = >>>>> protected by the solicitor-client or other applicable privileges), = >>>>> or constitute non-public information. Any use of this = >>>>> informationby anyone other than the intended recipient is = >>>>> prohibited. If you have >>> received this transmission in error, please immediately reply to the = >>> sender and delete this information from your system. Use, = >>> dissemination, distribution, or reproduction of this transmission by = >>> unintended recipients is not authorized and may be unlawful. >>>>> >>>>> >>>> >>>> ------------------------------------------------------------------- >>>> - >>>> - This transmission (including any attachments) may contain = >>>> confidential information, privileged material (including material = >>>> protected by the solicitor-client or other applicable privileges), = >>>> or constitute non-public information. Any use of this informationby = >>>> anyone other than the intended recipient is prohibited. If you have >>> received this transmission in error, please immediately reply to the = >>> sender and delete this information from your system. Use, = >>> dissemination, distribution, or reproduction of this transmission by = >>> unintended recipients is not authorized and may be unlawful. >>>> >>>> >>> >>> -------------------------------------------------------------------- >>> - This transmission (including any attachments) may contain = >>> confidential information, privileged material (including material = >>> protected by the solicitor-client or other applicable privileges), = >>> or constitute non-public information. Any use of this information by = >>> anyone other than the intended recipient is prohibited. If you have = >>> received this transmission in error, please immediately reply to the = >>> sender and delete this information from your system. Use, = >>> dissemination, distribution, or reproduction of this transmission by = >>> unintended recipients is not authorized and may be unlawful. >>> -------------------------------------------------------------------- >>> - This transmission (including any attachments) may contain = >>> confidential information, privileged material (including material = >>> protected by the solicitor-client or other applicable privileges), = >>> or constitute non-public information. Any use of this information by = >>> anyone other than the intended recipient is prohibited. If you have = >>> received this transmission in error, please immediately reply to the = >>> sender and delete this information from your system. Use, = >>> dissemination, distribution, or reproduction of this transmission by = >>> unintended recipients is not authorized and may be unlawful. >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Tue Oct 29 00:47:59 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C7511E819E for ; Tue, 29 Oct 2013 00:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=-1.449, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSZlQ8PvGNJt for ; Tue, 29 Oct 2013 00:47:53 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id F005B21E8096 for ; Tue, 29 Oct 2013 00:47:42 -0700 (PDT) X-AuditID: c1b4fb38-b7f178e00000233b-9d-526f681dba50 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id AB.E0.09019.D186F625; Tue, 29 Oct 2013 08:47:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 08:47:41 +0100 From: Christer Holmberg To: Andrew Allen , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUqRBKqAf4v0eC21ZkCIO4WJoKgpMAgADN42A= Date: Tue, 29 Oct 2013 07:47:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvja5sRn6Qwe8DJhb3521ltFix4QCr xdcfm9gcmD3+vv/A5DGrYS27x5IlP5kCmKO4bFJSczLLUov07RK4Ms7Pb2IqOMBXcXn6B9YG xovcXYycHBICJhJdq96wQthiEhfurWfrYuTiEBI4wihx6OFbJghnCaPExaO/WLoYOTjYBCwk uv9pgzSICJRLPD55mA3EFhZIlDh3fC8jRDxJ4u+K62wQtpXElYNz2EFsFgFViU+HHoIt4xXw lTh69xQzxPxfzBIvmucwgyQ4BTwltn3qZQKxGYEu+n5qDZjNLCAucevJfCaISwUkluw5zwxh i0q8fPwP6gNFiY+v9jFC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC 0rKAkWUVI0dxanFSbrqRwSZGYIwc3PLbYgfj5b82hxilOViUxHk/vnUOEhJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cCYKnrm6Ollv7fUsDWuOlQxLVjAYonKE5H2aXMZYhSs//e9k4mXcxRs 8ato6tvKq/Ct/evDc8r6wpXOUyzkTqq51+xUbpylf2JfzAL92Reu7rh/YRHXpricsCc3sxIm Xip0k+QwFIt7N+FG9LMrd89tus66ecqyN5JZa6b/Fi0I7hPdf4flsc5nJZbijERDLeai4kQA QHvkcV8CAAA= Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 07:47:59 -0000 Hi, > In actual usage many feature capability indicators (FCIs) are being used = to communicate URIs. The ones that communicate URIs listed below are just f= rom one 3GPP 3GPP specification (and there are several other specifications= that=20 > define feature capability indicators) and many of these FCIs were defined= by the authors of RFC 6809. So I think it has been found to be necessary t= o communicate URIs in FCIs. Usually these URIs are used as the Request-URI = of a SIP=20 > request and the URI is hosted by the server that included the FCI. > > If a UA indicates a URI hosted by it and a UA also indicates certain capa= bilities such as he supported SIP methods and SIP extensions I think you ca= n infer that the UA supports those methods and extensions and the UA can be= contacted at=20 > the URI. When contacting the UA at the indicated URI it seems to me to b= e a reasonable assumption to make that the methods and extensions also indi= cated are going to be supported. > > If the physical entity inserting the FCIs has different URIs that represe= nt logically different UAs (with different SIP methods and extensions suppo= rted) then the different logical UAs and their associated capabilities shou= ld be indicated in=20 > different Feature-Caps header fields. Again, I don't think one should make such "default assumption".=20 Instead, the g.xxx.yyy FCI specification needs to explicitly say that, when= used in conjunction with the sip.methods FCI, the sip.methods FCI indicate= s which SIP methods can be used when using the URI provided by the g.xxx.yy= y FCI. (Of course, the g.xxx.yyy FCI specification itself can also define which SI= P methods can be used, if the allowed methods are always the same, in which= case there is no need for sip.methods).=20 Regards, Christer From aallen@blackberry.com Tue Oct 29 07:25:52 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E5911E8273 for ; Tue, 29 Oct 2013 07:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pphbRLyOhhi for ; Tue, 29 Oct 2013 07:25:46 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9A03811E826E for ; Tue, 29 Oct 2013 07:25:36 -0700 (PDT) Received: from xct103ads.rim.net ([10.67.111.44]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 29 Oct 2013 10:25:33 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.03.0123.003; Tue, 29 Oct 2013 09:25:32 -0500 From: Andrew Allen To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUo+ZAiuycmUumaJncVjjxK5oKi8CQgAEa1ICAABo8MA== Date: Tue, 29 Oct 2013 14:25:31 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 14:25:52 -0000 Christer My responses inline Andrew -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] = Sent: Tuesday, October 29, 2013 3:48 AM To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators Hi, > In actual usage many feature capability indicators (FCIs) are being = > used to communicate URIs. The ones that communicate URIs listed below = > are just from one 3GPP 3GPP specification (and there are several other sp= ecifications that define feature capability indicators) and many of these F= CIs were defined by the authors of RFC 6809. So I think it has been found t= o be necessary to communicate URIs in FCIs. Usually these URIs are used as = the Request-URI of a SIP request and the URI is hosted by the server that i= ncluded the FCI. > > If a UA indicates a URI hosted by it and a UA also indicates certain = > capabilities such as he supported SIP methods and SIP extensions I think = you can infer that the UA supports those methods and extensions and the UA = can be contacted at the URI. When contacting the UA at the indicated URI i= t seems to me to be a reasonable assumption to make that the methods and ex= tensions also indicated are going to be supported. > > If the physical entity inserting the FCIs has different URIs that = > represent logically different UAs (with different SIP methods and extensi= ons supported) then the different logical UAs and their associated capabili= ties should be indicated in different Feature-Caps header fields. Again, I don't think one should make such "default assumption". = Instead, the g.xxx.yyy FCI specification needs to explicitly say that, when= used in conjunction with the sip.methods FCI, the sip.methods FCI indicate= s which SIP methods can be used when using the URI provided by the g.xxx.yy= y FCI. [AA] I am OK to go the approach that we state whether the scope of the FCI = (and the URI value of the FCI) is such that other FCIs in the SIP tree incl= ude in the same header field apply to that URI or not. (Of course, the g.xxx.yyy FCI specification itself can also define which SI= P methods can be used, if the allowed methods are always the same, in which= case there is no need for sip.methods). = [AA] I am not happy with that approach - I think that is "hidden magic" th= at some feature outside of SIP is defining what SIP features are supported. Regards, Christer --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From pkyzivat@alum.mit.edu Tue Oct 29 07:49:53 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC1021E8148 for ; Tue, 29 Oct 2013 07:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.056 X-Spam-Level: X-Spam-Status: No, score=0.056 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXLmJMZQmxSp for ; Tue, 29 Oct 2013 07:49:47 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 1A39F21E81B5 for ; Tue, 29 Oct 2013 07:42:13 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id j0SU1m0051swQuc532iCDk; Tue, 29 Oct 2013 14:42:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id j2iC1m00S3ZTu2S3b2iCXK; Tue, 29 Oct 2013 14:42:12 +0000 Message-ID: <526FC944.6090903@alum.mit.edu> Date: Tue, 29 Oct 2013 10:42:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Andrew Allen , Christer Holmberg , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383057732; bh=fuDnYv3uAzXrDdAWrKkGh5+ALCl4oiDZaVMMk7oTHLw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=j/v38z9HZOBYymz7JIrz26lPoffPEqmVTbc2DIEDFBzN839k0qAxV8m8nIRRX2K0K D2Uh/sIYTPSPppWGnxiEzGAYj7cFwdD9E9OVymENh+hET1eV6GgB4qakpCX6PylO51 L3pDocFU+HIjr73PAu94MTShxj8HUqG97xWrc7xu6aBEBzwb2h43UDN7Ap/p78fYGb OovWE/yJhM+yCsJ7sTDasQuJpUzRXtyodKLTr/wAIX5KBZoY+HV/1OB9ZTfoLlAksu XU349PAkAkMeOFJFupf1BO0iHIoL+Udrd3TgSNjZYZQfXo9giwPjBHRpCmAfraLppG j3NMSEGMXTcng== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 14:49:53 -0000 I would appreciate if the two of you would go off and come up with a proposal that you both agree is consistent with the language and intent of RFC 6809. What Christer is suggesting *might* work, though I reserve judgement until I see that actual language that you settle on. If you go that way, then I want to see an explanation of how the sip tree tags are specified. Thanks, Paul On 10/29/13 10:25 AM, Andrew Allen wrote: > Christer > > My responses inline > > Andrew > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, October 29, 2013 3:48 AM > To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org > Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators > > Hi, > >> In actual usage many feature capability indicators (FCIs) are being >> used to communicate URIs. The ones that communicate URIs listed below >> are just from one 3GPP 3GPP specification (and there are several other specifications that define feature capability indicators) and many of these FCIs were defined by the authors of RFC 6809. So I think it has been found to be necessary to communicate URIs in FCIs. Usually these URIs are used as the Request-URI of a SIP request and the URI is hosted by the server that included the FCI. >> >> If a UA indicates a URI hosted by it and a UA also indicates certain >> capabilities such as he supported SIP methods and SIP extensions I think you can infer that the UA supports those methods and extensions and the UA can be contacted at the URI. When contacting the UA at the indicated URI it seems to me to be a reasonable assumption to make that the methods and extensions also indicated are going to be supported. >> >> If the physical entity inserting the FCIs has different URIs that >> represent logically different UAs (with different SIP methods and extensions supported) then the different logical UAs and their associated capabilities should be indicated in different Feature-Caps header fields. > > Again, I don't think one should make such "default assumption". > > Instead, the g.xxx.yyy FCI specification needs to explicitly say that, when used in conjunction with the sip.methods FCI, the sip.methods FCI indicates which SIP methods can be used when using the URI provided by the g.xxx.yyy FCI. > > [AA] I am OK to go the approach that we state whether the scope of the FCI (and the URI value of the FCI) is such that other FCIs in the SIP tree include in the same header field apply to that URI or not. > > (Of course, the g.xxx.yyy FCI specification itself can also define which SIP methods can be used, if the allowed methods are always the same, in which case there is no need for sip.methods). > > [AA] I am not happy with that approach - I think that is "hidden magic" that some feature outside of SIP is defining what SIP features are supported. > > Regards, > > Christer > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > > From christer.holmberg@ericsson.com Tue Oct 29 08:28:25 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCE521E8167 for ; Tue, 29 Oct 2013 08:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.959 X-Spam-Level: X-Spam-Status: No, score=-4.959 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2uKUgX5x+6N for ; Tue, 29 Oct 2013 08:28:18 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEB821E8136 for ; Tue, 29 Oct 2013 08:27:53 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-85-526fd3f8d947 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 52.16.03802.8F3DF625; Tue, 29 Oct 2013 16:27:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 16:27:52 +0100 From: Christer Holmberg To: Paul Kyzivat , Andrew Allen , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUqRBKqAf4v0eC21ZkCIO4WJoKgpMAgADN42CAAGCwgIAABKkAgAAcNdiAAAFRfw== Date: Tue, 29 Oct 2013 15:27:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4FAAAA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> , <526FC944.6090903@alum.mit.edu> In-Reply-To: <526FC944.6090903@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4FAAAAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje6Py/lBBjPaFS3uz9vKaLFiwwFW i68/NrE5MHv8ff+ByWNWw1p2jyVLfjIFMEdx2aSk5mSWpRbp2yVwZZzqOMBacNGv4uj5s6wN jL2OXYwcHBICJhK7T/J2MXICmWISF+6tZwOxhQQOMUq8m2PUxcgFZC9hlGhd8JkZpJ5NwEKi +582SI2IQLnEl3/XWUBsYYFEiXPH9zJCxJMk/q64zgZhh0m8nPMAzGYRUJX4e2kWE4jNK+Ar MWn2PXaI+XNZJSZtOgJWxCmgI3HgxQWwoYxAB30/tQasgVlAXOLWk/lMEIcKSCzZc54ZwhaV ePn4HyuErSix82w7M0R9vsT0+ZvZIZYJSpyc+YRlAqPILCSjZiEpm4WkDCKuJ3Fj6hQ2CFtb YtnC18wQtq7EjH+HoGqsJbZNP8aMrGYBI8cqRvbcxMyc9HKjTYzAKDu45bfqDsY750QOMUpz sCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdHj/Nz1k+0Wf9N2y3kes0G+xTH7 3sr74Y9extz7f//P0Wf8gulh896uair6tY1/2cXU9B3/dnC7a//0UDPJ800yiygUY+xrPOHu KjrhdpbHGQn9fS4B625eTJjTrd3R7P2y/VOGyfMkd3HXtqTZvF9Nz93lVam7qe7Qr/+2r0Jv QROH7uOAr0osxRmJhlrMRcWJABiwPtOAAgAA Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 15:28:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4FAAAAESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >I would appreciate if the two of you would go off and come up with a >proposal that you both agree is consistent with the language and intent >of RFC 6809. > >What Christer is suggesting *might* work, though I reserve judgement >until I see that actual language that you settle on. If you go that way, >then I want to see an explanation of how the sip tree tags are specified. I think we would have to say that the sip.x FCIs as such don't provide much= information. Instead, they can be used together with OTHER FCIs, to provid= e additional information about those OTHER FCIs. But, the FCI specifcation = of such OTHER FCI MUST describe which sip.x FCIs are used to provide additi= onal information, and how. Regards, Chrsiter On 10/29/13 10:25 AM, Andrew Allen wrote: > Christer > > My responses inline > > Andrew > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, October 29, 2013 3:48 AM > To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org > Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipcore-s= ip-tree-cap-indicators > > Hi, > >> In actual usage many feature capability indicators (FCIs) are being >> used to communicate URIs. The ones that communicate URIs listed below >> are just from one 3GPP 3GPP specification (and there are several other s= pecifications that define feature capability indicators) and many of these = FCIs were defined by the authors of RFC 6809. So I think it has been found = to be necessary to communicate URIs in FCIs. Usually these URIs are used as= the Request-URI of a SIP request and the URI is hosted by the server that = included the FCI. >> >> If a UA indicates a URI hosted by it and a UA also indicates certain >> capabilities such as he supported SIP methods and SIP extensions I think= you can infer that the UA supports those methods and extensions and the UA= can be contacted at the URI. When contacting the UA at the indicated URI = it seems to me to be a reasonable assumption to make that the methods and e= xtensions also indicated are going to be supported. >> >> If the physical entity inserting the FCIs has different URIs that >> represent logically different UAs (with different SIP methods and extens= ions supported) then the different logical UAs and their associated capabil= ities should be indicated in different Feature-Caps header fields. > > Again, I don't think one should make such "default assumption". > > Instead, the g.xxx.yyy FCI specification needs to explicitly say that, wh= en used in conjunction with the sip.methods FCI, the sip.methods FCI indica= tes which SIP methods can be used when using the URI provided by the g.xxx.= yyy FCI. > > [AA] I am OK to go the approach that we state whether the scope of the FC= I (and the URI value of the FCI) is such that other FCIs in the SIP tree in= clude in the same header field apply to that URI or not. > > (Of course, the g.xxx.yyy FCI specification itself can also define which = SIP methods can be used, if the allowed methods are always the same, in whi= ch case there is no need for sip.methods). > > [AA] I am not happy with that approach - I think that is "hidden magic" = that some feature outside of SIP is defining what SIP features are supporte= d. > > Regards, > > Christer > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > > --_000_7594FB04B1934943A5C02806D1A2204B1C4FAAAAESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

 

>I would appreciate if the two of you would go = off and come up with a
>proposal that you both agree is consistent with the language and intent=
>of RFC 6809.
>
>What Christer is suggesting *might* work, though I reserve judgement >until I see that actual language that you settle on. If you go that way= ,
>then I want to see an explanation of how the sip tree tags are specifie= d.
I think we would have to say that the sip.x FCIs a= s such don't provide much information. Instead, they can be used together w= ith OTHER FCIs, to provide additional information about those OTH= ER FCIs. But, the FCI specifcation of such OTHER FCI MUST describe which sip.x FCIs are used to provide additional informat= ion, and how.
 
Regards,
 
Chrsiter
 

On 10/29/13 10:25 AM, Andrew Allen wrote:
> Christer
>
> My responses inline
>
> Andrew
>
> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Tuesday, October 29, 2013 3:48 AM
> To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org
> Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipcor= e-sip-tree-cap-indicators
>
> Hi,
>
>> In actual usage many feature capability indicators (FCIs) are bein= g
>> used to communicate URIs. The ones that communicate URIs listed be= low
>> are just from one 3GPP 3GPP specification (and there are several o= ther specifications that define feature capability indicators) and many of = these FCIs were defined by the authors of RFC 6809. So I think it has been = found to be necessary to communicate URIs in FCIs. Usually these URIs are used as the Request-URI of a SIP request a= nd the URI is hosted by the server that included the FCI.
>>
>> If a UA indicates a URI hosted by it and a UA also indicates certa= in
>> capabilities such as he supported SIP methods and SIP extensions I= think you can infer that the UA supports those methods and extensions and = the UA can be contacted at the URI.  When contacting the UA at the ind= icated URI it seems to me to be a reasonable assumption to make that the methods and extensions also indicated are goin= g to be supported.
>>
>> If the physical entity inserting the FCIs has different URIs that<= br> >> represent logically different UAs (with different SIP methods and = extensions supported) then the different logical UAs and their associated c= apabilities should be indicated in different  Feature-Caps header fiel= ds.
>
> Again, I don't think one should make such "default assumption&quo= t;.
>
> Instead, the g.xxx.yyy FCI specification needs to explicitly say that,= when used in conjunction with the sip.methods FCI, the sip.methods FCI ind= icates which SIP methods can be used when using the URI provided by the g.x= xx.yyy FCI.
>
> [AA] I am OK to go the approach that we state whether the scope of the= FCI (and the URI value of the FCI) is such that other FCIs in the SIP tree= include in the same header field apply to that URI or not.
>
> (Of course, the g.xxx.yyy FCI specification itself can also define whi= ch SIP methods can be used, if the allowed methods are always the same, in = which case there is no need for sip.methods).
>
> [AA] I am not happy with that approach - I think that is "hidden = magic"  that some feature outside of SIP is defining what SIP fea= tures are supported.
>
> Regards,
>
> Christer
> ---------------------------------------------------------------------<= br> > This transmission (including any attachments) may contain confidential= information, privileged material (including material protected by the soli= citor-client or other applicable privileges), or constitute non-public info= rmation. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>
>

--_000_7594FB04B1934943A5C02806D1A2204B1C4FAAAAESESSMB209erics_-- From pkyzivat@alum.mit.edu Tue Oct 29 09:09:56 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BD411E8302 for ; Tue, 29 Oct 2013 09:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.361 X-Spam-Level: X-Spam-Status: No, score=0.361 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_31=0.6, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu47uove3MiR for ; Tue, 29 Oct 2013 09:09:51 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id C11A611E827E for ; Tue, 29 Oct 2013 09:09:42 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta01.westchester.pa.mail.comcast.net with comcast id j0qv1m0041ZXKqc5149imN; Tue, 29 Oct 2013 16:09:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id j49h1m00P3ZTu2S3h49hAi; Tue, 29 Oct 2013 16:09:42 +0000 Message-ID: <526FDDC5.6050201@alum.mit.edu> Date: Tue, 29 Oct 2013 12:09:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Christer Holmberg , Andrew Allen , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> , <526FC944.6090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4FAAAA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4FAAAA@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383062982; bh=CIgrXDwAsn1nxhm6Xya3rOx9o3D+M4Y6E2nFAsqmAGs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nZ+9VZ+UnjKgs5/Pia+Oat7oe6VHsCIZL5diSs6TB+CB4BFr86GjZuwJEvU5kZVuX 9x7JjPGj/yekZsTLs4WazOYqcuiXLzTWyO1Vd25B4rcU7tYMkmN1jUiyb6YBMr1Ob7 4qa7qiwIbFwsfw+nWCSakV1/MkYTE2EaJVQcH9DY07pWdAs/LYcwatwqvNC3ttBCLx iSS4LzQW4K1mdNjWxIu8S7sBbkY07mgM/Exw0Ha7HB0FS+VjD5jt0KYvbhFrTyJnOC /7nwRR8J/vaZnuOcmP4GIVIFA1Ob1lWE+SxmVqvRbjYR0uLdsJNT0oCyDnCLmqjWMa 6NAiRNhCtkBFw== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 16:09:56 -0000 Christer, What you say below seems plausible as a way forward. It does present a potential problem: Suppose you do that. And then another tag g.xxx.foo is defined with a URI that identifies a foo server and a rule that says the presence or absence of +sip.audio and +sip.video indicates whether the foo server at the URI supports audio and video. Then another tag g.xxx.bar is defined with a URI that identifies a bar server and a rule that says the presence or absence of +sip.audio and +sip.video indicates whether the foo server at the URI supports audio and video. Then something inserts a Feature-Caps entry. It wants to indicate a foo server that supports audio, and a bar server that supports video. It can't do that in a single entry. It could emit two entries as Andrew suggested. Is that valid? I think it will be necessary to spell out the rules for this sort of usage. And this won't necessarily be just for these tags in the sip tree. It could apply to other tags as well. If feels more like an extension (or maybe just a clarification) of 6809. Thanks, Paul On 10/29/13 11:27 AM, Christer Holmberg wrote: > Hi, > >>I would appreciate if the two of you would go off and come up with a >>proposal that you both agree is consistent with the language and intent >>of RFC 6809. >> >>What Christer is suggesting *might* work, though I reserve judgement >>until I see that actual language that you settle on. If you go that way, >>then I want to see an explanation of how the sip tree tags are specified. > I think we would have to say that the sip.x FCIs as such don't provide > much information. Instead, they can be used together with OTHER FCIs, to > provide additional information about those OTHER FCIs. But, the FCI > specifcation of such OTHER FCI MUST describe which sip.x FCIs are used > to provide additional information, and how. > Regards, > Chrsiter > > On 10/29/13 10:25 AM, Andrew Allen wrote: >> Christer >> >> My responses inline >> >> Andrew >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Tuesday, October 29, 2013 3:48 AM >> To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org >> Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators >> >> Hi, >> >>> In actual usage many feature capability indicators (FCIs) are being >>> used to communicate URIs. The ones that communicate URIs listed below >>> are just from one 3GPP 3GPP specification (and there are several other specifications that define feature capability indicators) and many of these FCIs were defined by the authors of RFC 6809. So I think it has been found to be necessary to communicate URIs in FCIs. Usually these URIs are used as the Request-URI of a SIP > request and the URI is hosted by the server that included the FCI. >>> >>> If a UA indicates a URI hosted by it and a UA also indicates certain >>> capabilities such as he supported SIP methods and SIP extensions I think you can infer that the UA supports those methods and extensions and the UA can be contacted at the URI. When contacting the UA at the indicated URI it seems to me to be a reasonable assumption to make that the methods and extensions also indicated are > going to be supported. >>> >>> If the physical entity inserting the FCIs has different URIs that >>> represent logically different UAs (with different SIP methods and extensions supported) then the different logical UAs and their associated capabilities should be indicated in different Feature-Caps header fields. >> >> Again, I don't think one should make such "default assumption". >> >> Instead, the g.xxx.yyy FCI specification needs to explicitly say that, when used in conjunction with the sip.methods FCI, the sip.methods FCI indicates which SIP methods can be used when using the URI provided by the g.xxx.yyy FCI. >> >> [AA] I am OK to go the approach that we state whether the scope of the FCI (and the URI value of the FCI) is such that other FCIs in the SIP tree include in the same header field apply to that URI or not. >> >> (Of course, the g.xxx.yyy FCI specification itself can also define which SIP methods can be used, if the allowed methods are always the same, in which case there is no need for sip.methods). >> >> [AA] I am not happy with that approach - I think that is "hidden magic" that some feature outside of SIP is defining what SIP features are supported. >> >> Regards, >> >> Christer >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >> >> > From vkg@bell-labs.com Tue Oct 29 09:49:40 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BF511E8240 for ; Tue, 29 Oct 2013 09:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.506 X-Spam-Level: X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqlIB+JgZf0H for ; Tue, 29 Oct 2013 09:49:35 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 49F9221F9DED for ; Tue, 29 Oct 2013 09:47:32 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r9TGl9ni010947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Oct 2013 11:47:10 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r9TGl8w2007806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Oct 2013 11:47:08 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r9TGl6rL001692; Tue, 29 Oct 2013 11:47:08 -0500 (CDT) Message-ID: <526FE67B.80400@bell-labs.com> Date: Tue, 29 Oct 2013 11:46:51 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Adam Roach References: <5266E8EE.5060609@nostrum.com> In-Reply-To: <5266E8EE.5060609@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 16:49:40 -0000 On 10/22/2013 04:06 PM, Adam Roach wrote: > [as chair] > > It has been brought to our attention that there might be some confusion > about the status of and venue for discussing the > draft-johansson-sip-dual-stack document. > > The SIPCORE chairs, together with our Area Director and the DISPATCH > chairs, have determined that the proper working group for this work, if > it proceeds, is SIPCORE. That said, we have not yet heard enough from > the community to yet determine whether to add a deliverable to the > SIPCORE charter for IPv4/IPv6 interactions. > > So, the first step here is to determine whether there's enough interest > to add a milestone for updating or clarifying RFC 3263 procedures when > both A and AAAA records exist for a single authority. Adam: I am not averse to adopting this work but do want to point out that it may end up impacting more than rfc3263. Contrary to what draft-johansson-sip-dual-stack states, rfc6157 also deals with the signaling aspects of dual-stack SIP entities (see S3 of rfc6157). The recommendation in rfc6157 is for autonomous systems to deploy dual- stack servers or both IPv4-only and IPv6-only and populate DNS with A and AAAA RRs. My understanding is that draft-johansson-sip-dual-stack does not obviate these recommendations but rather adds an additional requirement that DNS be populated such that a certain address family is preferred. So, as we grapple with where to do this work, it may be that it touches more than rfc3263 and may impact rfc6157 as well. We do not want to end up in a situation where there are multiple drafts specifying dual- stack behaviour. I don't know whether it makes sense for draft-johansson-sip-dual-stack to update S3 of rfc6157, but note that rfc6157 does not update rfc3263. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From aallen@blackberry.com Tue Oct 29 10:03:43 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB6721F9B7E for ; Tue, 29 Oct 2013 10:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hrkst5ZasxUM for ; Tue, 29 Oct 2013 10:03:38 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4A21821F9E33 for ; Tue, 29 Oct 2013 09:57:22 -0700 (PDT) Received: from xct101ads.rim.net ([10.67.111.42]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 29 Oct 2013 12:57:13 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.03.0123.003; Tue, 29 Oct 2013 11:57:12 -0500 From: Andrew Allen To: Paul Kyzivat , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUo+ZAiuycmUumaJncVjjxK5oKi8CQgAEa1ICAABo8MIAAWZQAgAAMwoCAAAuwgP//t/4Q Date: Tue, 29 Oct 2013 16:57:11 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> , <526FC944.6090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4FAAAA@ESESSMB209.ericsson.se> <526FDDC5.6050201@alum.mit.edu> In-Reply-To: <526FDDC5.6050201@alum.mit.edu> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 17:03:43 -0000 Do we agree that if a UA indicates it supports a SIP Method or a SIP extens= ion or a SIP event package then that UA supports that SIP Method or that SI= P extension or that SIP event package? If that same UA also indicates a URI that it can be reached at then that UA= that can be reached at the advertised URI also supports that SIP Method or= that SIP extension or that SIP event package - agree? So to me the issue to clarify in the global tree FCI that advertises the UR= I is whether the URI is hosted by the same UA that also indicates the SIP c= apabilities in the SIP tree FCIs. Does that make sense? Andrew -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] = Sent: Tuesday, October 29, 2013 12:10 PM To: Christer Holmberg; Andrew Allen; sipcore@ietf.org Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators Christer, What you say below seems plausible as a way forward. It does present a potential problem: Suppose you do that. And then another tag g.xxx.foo is defined with a URI t= hat identifies a foo server and a rule that says the presence or absence of= +sip.audio and +sip.video indicates whether the foo server at the URI supp= orts audio and video. Then another tag g.xxx.bar is defined with a URI that identifies a bar serv= er and a rule that says the presence or absence of +sip.audio and = +sip.video indicates whether the foo server at the URI supports audio and video. Then something inserts a Feature-Caps entry. It wants to indicate a foo = server that supports audio, and a bar server that supports video. It = can't do that in a single entry. It could emit two entries as Andrew = suggested. Is that valid? I think it will be necessary to spell out the rules for this sort of = usage. And this won't necessarily be just for these tags in the sip = tree. It could apply to other tags as well. If feels more like an = extension (or maybe just a clarification) of 6809. Thanks, Paul On 10/29/13 11:27 AM, Christer Holmberg wrote: > Hi, > >>I would appreciate if the two of you would go off and come up with a >>proposal that you both agree is consistent with the language and intent >>of RFC 6809. >> >>What Christer is suggesting *might* work, though I reserve judgement >>until I see that actual language that you settle on. If you go that way, >>then I want to see an explanation of how the sip tree tags are specified. > I think we would have to say that the sip.x FCIs as such don't provide > much information. Instead, they can be used together with OTHER FCIs, to > provide additional information about those OTHER FCIs. But, the FCI > specifcation of such OTHER FCI MUST describe which sip.x FCIs are used > to provide additional information, and how. > Regards, > Chrsiter > > On 10/29/13 10:25 AM, Andrew Allen wrote: >> Christer >> >> My responses inline >> >> Andrew >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Tuesday, October 29, 2013 3:48 AM >> To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org >> Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipcore-= sip-tree-cap-indicators >> >> Hi, >> >>> In actual usage many feature capability indicators (FCIs) are being >>> used to communicate URIs. The ones that communicate URIs listed below >>> are just from one 3GPP 3GPP specification (and there are several other = specifications that define feature capability indicators) and many of these= FCIs were defined by the authors of RFC 6809. So I think it has been found= to be necessary to communicate URIs in FCIs. Usually these URIs are used = as the Request-URI of a SIP > request and the URI is hosted by the server that included the FCI. >>> >>> If a UA indicates a URI hosted by it and a UA also indicates certain >>> capabilities such as he supported SIP methods and SIP extensions I thin= k you can infer that the UA supports those methods and extensions and the U= A can be contacted at the URI. When contacting the UA at the indicated URI= it seems to me to be a reasonable assumption to make that the methods and= extensions also indicated are > going to be supported. >>> >>> If the physical entity inserting the FCIs has different URIs that >>> represent logically different UAs (with different SIP methods and exten= sions supported) then the different logical UAs and their associated capabi= lities should be indicated in different Feature-Caps header fields. >> >> Again, I don't think one should make such "default assumption". >> >> Instead, the g.xxx.yyy FCI specification needs to explicitly say that, w= hen used in conjunction with the sip.methods FCI, the sip.methods FCI indic= ates which SIP methods can be used when using the URI provided by the g.xxx= .yyy FCI. >> >> [AA] I am OK to go the approach that we state whether the scope of the F= CI (and the URI value of the FCI) is such that other FCIs in the SIP tree i= nclude in the same header field apply to that URI or not. >> >> (Of course, the g.xxx.yyy FCI specification itself can also define which= SIP methods can be used, if the allowed methods are always the same, in wh= ich case there is no need for sip.methods). >> >> [AA] I am not happy with that approach - I think that is "hidden magic" = that some feature outside of SIP is defining what SIP features are support= ed. >> >> Regards, >> >> Christer >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential i= nformation, privileged material (including material protected by the solici= tor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recip= ient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >> >> > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From pkyzivat@alum.mit.edu Tue Oct 29 10:14:01 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64D921E8056 for ; Tue, 29 Oct 2013 10:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.239 X-Spam-Level: X-Spam-Status: No, score=-0.239 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsVn762+mNcC for ; Tue, 29 Oct 2013 10:13:42 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 5012521F9EFE for ; Tue, 29 Oct 2013 10:05:22 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta06.westchester.pa.mail.comcast.net with comcast id j4Vl1m0020xGWP85655Fib; Tue, 29 Oct 2013 17:05:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id j55F1m00Q3ZTu2S3Y55Fpy; Tue, 29 Oct 2013 17:05:15 +0000 Message-ID: <526FEACB.1000202@alum.mit.edu> Date: Tue, 29 Oct 2013 13:05:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <5266E8EE.5060609@nostrum.com> <526FE67B.80400@bell-labs.com> In-Reply-To: <526FE67B.80400@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383066315; bh=reKgQGM1zljrx8sbqFZFMmbMWYwUQkDwxbI36z7A9tI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sQYOdyn9lexbHVNSUnrkWsNj/XSsxLyDJHuDEeCFMaKjfJFyB1RXt8cx/d5MQiLJU 7KqlkIal02OBAub/0bpB43q93T+ZAWqKjhjysim6wffo/HalmBWOWPY8tKkN8DOhM1 QWKYgm/1xlm7gbxaqXQ+zftCbiYhkGOZ1z7cfncjucuDsq4QHFmuPB3bzsYS54+iLJ QCdw4kYeJQ/piS/wf5L+fkTYTJuMb76L6cfvoy7ATA9GhRVtR/abZ71QLr5HK3rVXz ilms/x00tRpYZQQdnmCVNeiZKiSIN5F0y5Y65peplIg4WrLthNII2fiYMZ2cCQR2Qm +nV+blZM2rbPw== Subject: Re: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 17:14:01 -0000 Vijay, IMO we have now seen enough support to justify some sort of work item. One thing we need to decide is how broadly to scope the work item. We could try to scope it as narrowly as possible - about how a dual stack server should deal with SIP URIs containing domain names. Or we could scope it more broadly to clarifying all the aspects of mixing IPv4 and IPv6 usage in SIP. I'd be interested in hearing opinions about that. Thanks, Paul On 10/29/13 12:46 PM, Vijay K. Gurbani wrote: > On 10/22/2013 04:06 PM, Adam Roach wrote: >> [as chair] >> >> It has been brought to our attention that there might be some confusion >> about the status of and venue for discussing the >> draft-johansson-sip-dual-stack document. >> >> The SIPCORE chairs, together with our Area Director and the DISPATCH >> chairs, have determined that the proper working group for this work, if >> it proceeds, is SIPCORE. That said, we have not yet heard enough from >> the community to yet determine whether to add a deliverable to the >> SIPCORE charter for IPv4/IPv6 interactions. >> >> So, the first step here is to determine whether there's enough interest >> to add a milestone for updating or clarifying RFC 3263 procedures when >> both A and AAAA records exist for a single authority. > > Adam: I am not averse to adopting this work but do want to point out > that it may end up impacting more than rfc3263. > > Contrary to what draft-johansson-sip-dual-stack states, rfc6157 also > deals with the signaling aspects of dual-stack SIP entities (see > S3 of rfc6157). > > The recommendation in rfc6157 is for autonomous systems to deploy dual- > stack servers or both IPv4-only and IPv6-only and populate DNS with > A and AAAA RRs. My understanding is that draft-johansson-sip-dual-stack > does not obviate these recommendations but rather adds an additional > requirement that DNS be populated such that a certain address family > is preferred. > > So, as we grapple with where to do this work, it may be that it touches > more than rfc3263 and may impact rfc6157 as well. We do not want to > end up in a situation where there are multiple drafts specifying dual- > stack behaviour. > > I don't know whether it makes sense for draft-johansson-sip-dual-stack > to update S3 of rfc6157, but note that rfc6157 does not update rfc3263. > > Thanks, > > - vijay From pkyzivat@alum.mit.edu Tue Oct 29 10:26:59 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF48921F8415 for ; Tue, 29 Oct 2013 10:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.359 X-Spam-Level: X-Spam-Status: No, score=0.359 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_31=0.6, J_CHICKENPOX_37=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9udFPi-lFw4 for ; Tue, 29 Oct 2013 10:26:31 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 9872D21F9D8B for ; Tue, 29 Oct 2013 10:25:55 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta10.westchester.pa.mail.comcast.net with comcast id izs41m0060QuhwU5A5Rttj; Tue, 29 Oct 2013 17:25:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id j5Rt1m00E3ZTu2S3N5RtfF; Tue, 29 Oct 2013 17:25:53 +0000 Message-ID: <526FEFA1.2070409@alum.mit.edu> Date: Tue, 29 Oct 2013 13:25:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Andrew Allen , Christer Holmberg , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> , <526FC944.6090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4FAAAA@ESESSMB209.ericsson.se> <526FDDC5.6050201@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383067553; bh=g2VmESHTMcLBxw+9Z3L6ZJ7hQrMUQCN1KWfFj+LDgZQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bQtl8aV+AuZxRNkhyxQhrgb9KBLNnToToRqQuALlfFhEqmJegQ9fSmshbL+bffTzn 0g07GZeBM7zJrISiJ16b06QlZS3NNlW+Sv+x3J9aveNdV7DW+ZRJSWfopvhUO9rjlc 6qH9OZFuu1119oasJIU/whHIgKu1UsHoU8sndm7Cm29SDvBYugTY/BMZfDHI6tqlz2 rl52/kqiNYjoH1HkiAlGKQg/p/AYhGod0RpEQ6LNTjC23eCNIi4RnQ9Y2XRRou2zd7 EkS79i+/n0w5fShMryotzp9dZJOAXbjp8JIfVvJBAQ0RuaGNRK0dL/0E5PvoGB//oC k5akvTmjRKbUQ== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 17:27:00 -0000 On 10/29/13 12:57 PM, Andrew Allen wrote: > > Do we agree that if a UA indicates it supports a SIP Method or a SIP extension or a SIP event package then that UA supports that SIP Method or that SIP extension or that SIP event package? Are you are asking this in the context of 3840? This seems appropriate. But "supports" is a bit slippery. I think we should be able to assume that support was there at the time the indication was made. But it won't necessarily remain true forever. And there is no specification of a minimum time that it must remain valid. Also, "support" also can be nuanced in other ways. For instance isFocus may be true for certain dialogs and not others. So the knowledge imparted by these is "fuzzy". > If that same UA also indicates a URI that it can be reached at then that UA that can be reached at the advertised URI also supports that SIP Method or that SIP extension or that SIP event package - agree? In the context of 3840, yes. (Given the caveats above.) > So to me the issue to clarify in the global tree FCI that advertises the URI is whether the URI is hosted by the same UA that also indicates the SIP capabilities in the SIP tree FCIs. > > Does that make sense? I guess this would be an alternative approach to the one Christer suggested. IIUC, you are saying that the definition of g.xxx.foo might say: - the server posting this FC is a foo server - the server posting this FC is reachable out of dialog at the supplied URI And then the FCI sip.x tag descriptions would say that they describe capabilities of the server posting the FC entry. This seems a little weird, but it might fly. I'd like to hear what other people think. Thanks, Paul > Andrew > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, October 29, 2013 12:10 PM > To: Christer Holmberg; Andrew Allen; sipcore@ietf.org > Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators > > Christer, > > What you say below seems plausible as a way forward. > > It does present a potential problem: > > Suppose you do that. And then another tag g.xxx.foo is defined with a URI that identifies a foo server and a rule that says the presence or absence of +sip.audio and +sip.video indicates whether the foo server at the URI supports audio and video. > > Then another tag g.xxx.bar is defined with a URI that identifies a bar server and a rule that says the presence or absence of +sip.audio and > +sip.video indicates whether the foo server at the URI supports audio > and video. > > Then something inserts a Feature-Caps entry. It wants to indicate a foo > server that supports audio, and a bar server that supports video. It > can't do that in a single entry. It could emit two entries as Andrew > suggested. Is that valid? > > I think it will be necessary to spell out the rules for this sort of > usage. And this won't necessarily be just for these tags in the sip > tree. It could apply to other tags as well. If feels more like an > extension (or maybe just a clarification) of 6809. > > Thanks, > Paul > > On 10/29/13 11:27 AM, Christer Holmberg wrote: >> Hi, >> >>> I would appreciate if the two of you would go off and come up with a >>> proposal that you both agree is consistent with the language and intent >>> of RFC 6809. >>> >>> What Christer is suggesting *might* work, though I reserve judgement >>> until I see that actual language that you settle on. If you go that way, >>> then I want to see an explanation of how the sip tree tags are specified. >> I think we would have to say that the sip.x FCIs as such don't provide >> much information. Instead, they can be used together with OTHER FCIs, to >> provide additional information about those OTHER FCIs. But, the FCI >> specifcation of such OTHER FCI MUST describe which sip.x FCIs are used >> to provide additional information, and how. >> Regards, >> Chrsiter >> >> On 10/29/13 10:25 AM, Andrew Allen wrote: >>> Christer >>> >>> My responses inline >>> >>> Andrew >>> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Tuesday, October 29, 2013 3:48 AM >>> To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org >>> Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators >>> >>> Hi, >>> >>>> In actual usage many feature capability indicators (FCIs) are being >>>> used to communicate URIs. The ones that communicate URIs listed below >>>> are just from one 3GPP 3GPP specification (and there are several other specifications that define feature capability indicators) and many of these FCIs were defined by the authors of RFC 6809. So I think it has been found to be necessary to communicate URIs in FCIs. Usually these URIs are used as the Request-URI of a SIP >> request and the URI is hosted by the server that included the FCI. >>>> >>>> If a UA indicates a URI hosted by it and a UA also indicates certain >>>> capabilities such as he supported SIP methods and SIP extensions I think you can infer that the UA supports those methods and extensions and the UA can be contacted at the URI. When contacting the UA at the indicated URI it seems to me to be a reasonable assumption to make that the methods and extensions also indicated are >> going to be supported. >>>> >>>> If the physical entity inserting the FCIs has different URIs that >>>> represent logically different UAs (with different SIP methods and extensions supported) then the different logical UAs and their associated capabilities should be indicated in different Feature-Caps header fields. >>> >>> Again, I don't think one should make such "default assumption". >>> >>> Instead, the g.xxx.yyy FCI specification needs to explicitly say that, when used in conjunction with the sip.methods FCI, the sip.methods FCI indicates which SIP methods can be used when using the URI provided by the g.xxx.yyy FCI. >>> >>> [AA] I am OK to go the approach that we state whether the scope of the FCI (and the URI value of the FCI) is such that other FCIs in the SIP tree include in the same header field apply to that URI or not. >>> >>> (Of course, the g.xxx.yyy FCI specification itself can also define which SIP methods can be used, if the allowed methods are always the same, in which case there is no need for sip.methods). >>> >>> [AA] I am not happy with that approach - I think that is "hidden magic" that some feature outside of SIP is defining what SIP features are supported. >>> >>> Regards, >>> >>> Christer >>> --------------------------------------------------------------------- >>> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the >> sender and delete this information from your system. Use, dissemination, >> distribution, or reproduction of this transmission by unintended >> recipients is not authorized and may be unlawful. >>> >>> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > > From aallen@blackberry.com Tue Oct 29 10:32:58 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924EE11E818C for ; Tue, 29 Oct 2013 10:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4n3dALgFQkKd for ; Tue, 29 Oct 2013 10:32:18 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 90E2D11E8190 for ; Tue, 29 Oct 2013 10:31:10 -0700 (PDT) Received: from xct102ads.rim.net ([10.67.111.43]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 29 Oct 2013 13:30:40 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.03.0123.003; Tue, 29 Oct 2013 12:30:40 -0500 From: Andrew Allen To: "sipcore@ietf.org" Thread-Topic: Questions regarding use of REFER by RFC 6665 compliant UAs Thread-Index: Ac7UwRyQm5QbMo/XTta8UIVCzdMI+Q== Date: Tue, 29 Oct 2013 17:30:39 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338E40340XMB104ADSrimnet_" MIME-Version: 1.0 Subject: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 17:32:59 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338E40340XMB104ADSrimnet_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Recently there has been some offline discussion regarding the impact of RFC= 6665 on the use of REFER. Particularly on whether an RFC 6665 compliant UA= can send a REFER using a dialog created by another SIP method other than f= or interoperability with UAs that don't support GRUU and RFC 6665. RFC 6665 deprecates dialog reuse for subscriptions. REFER can create also c= reate an implicit subscription. RFC 6665 states: .... the dialog reuse technique described in RFC 3265 is now deprec= ated. This dialog-sharing technique has also historically been used as a means for targeting an event package at a dialog. This usage can be seen, for example, in certain applications of the REFER method [RFC3515]. With the removal of dialog reuse, an alternate (and more explicit) means of targeting dialogs needs to be used for this type of correlation. The appropriate means of such targeting is left up to the actual event packages. Candidates include the "Target-Dialog" header field [RFC4538], the "Join" header field [RFC3911], and the "Replaces" header field [RFC3891], depending on the semantics desired. And Further note that the prohibition on reusing dialogs does not exempt implicit subscriptions created by the REFER method. This means that implementations complying with this specification are required to use the "Target-Dialog" mechanism described in [RFC4538] when the remote target is a GRUU. However RFC 4488 provides a means to request a REFER recipient not to creat= e an implicit subscription through the use of Refer-Sub: false. However the= text of RFC 4488 does not require that the REFER recipient not create an i= mplicit subscription since RFC 4488 states: If the REFER-Recipient supports the extension and is willing to process = the REFER transaction without establishing an implicit subscription, it MUS= T insert the "Refer-Sub" header field set to "false" in the 2xx response to= the REFER-Issuer. The key words here are "and is WILLING to process the REFER transaction wit= hout establishing an implicit subscription" so there is always the possibil= ity that a subscription will be created even if norefersub is supported and= Refer-Sub header field is set to FALSE. However RFC 5057 seems to be in conflict with RFC 4488 in this regard stati= ng: Dialogs with multiple usages arise when a usage-creating action occurs inside an existing dialog. Such actions include accepting a REFER or SUBSCRIBE issued inside a dialog established with an INVITE request. Multiple REFERs within a dialog create multiple subscriptions, each of which is a new dialog usage sharing common dialog state. (Note that any REFER issued utilizing the subscription-suppression mechanism specified in [2] creates no new usage.) Similarly, an endpoint in a dialog established with an INVITE might subscribe to its peer's Key Press Markup Language (KPML) [3] and later issue a REFER, resulting in three dialog usages sharing common dialog state. So the first question is if an RFC 6665 compliant UA indicated either Requi= re: norefersub or knows that the REFER recipient supports norefersub and al= so indicates Refer-Sub: False in the REFER request can that REFER request = be sent on a dialog created by another Method (in the safe knowledge that n= o subscription will be created)? If the answer to the first question is no - an implicit subscription could = still be created. Can some other knowledge that the REFER recipient will not create an implic= it subscription - such as the definition in another specification outside o= f IETF of a feature that mandates that no subscription be created by the RE= FER recipient and the indication of the support of such a feature by the RE= FER recipient in a global tree media feature tag has been received by the R= EFER sender. Does this allow an RFC 6665 UA to send the REFER on a dialog c= reated by another Method? I have discussed the issue with Adam Roach offline and his view and mine is= that RFC 6665 UAs do not send REFER requests sent on a dialog created by a= nother Method except for interoperability with UAs that don't support GRUU = and RFC 6665. What is the view of the rest of the community? Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD2338E40340XMB104ADSrimnet_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

 

Recently there has been some offline discussion rega= rding the impact of RFC 6665 on the use of REFER. Particularly on whether a= n RFC 6665 compliant UA can send a REFER using a dialog created by another = SIP method other than for interoperability with UAs that don’t support GRUU and RFC 6665.

 

RFC 6665 deprecates dialog reuse for subscriptions. = REFER can create also create an implicit subscription.

 

RFC 6665 states:

 

   &nbs= p;    …. the dialog reuse technique described in RFC 3265 is now deprecated.<= o:p>

 

   This dialog-sharing technique ha= s also historically been used as a

   means for targeting an event pac= kage at a dialog.  This usage can be

   seen, for example, in certain ap= plications of the REFER method

   [RFC3515].  With the remova= l of dialog reuse, an alternate (and more

   explicit) means of targeting dia= logs needs to be used for this type

   of correlation.  The approp= riate means of such targeting is left up

   to the actual event packages.&nb= sp; Candidates include the "Target-Dialog"

   header field [RFC4538], the &quo= t;Join" header field [RFC3911], and the

   "Replaces" header fiel= d [RFC3891], depending on the semantics

=    desired.

=  

= And

=  

      Further note t= hat the prohibition on reusing dialogs does not

      exempt implici= t subscriptions created by the REFER method.  This

      means that imp= lementations complying with this specification are

      required to us= e the "Target-Dialog" mechanism described in

      [RFC4538] when= the remote target is a GRUU.

 

 

However RFC 4488 provides a means to request a REFER= recipient not to create an implicit subscription through the use of Refer-= Sub: false. However the text of RFC 4488 does not require that the REFER re= cipient not create an implicit subscription since RFC 4488 states:

 

   If the REFER-Recipient supports = the extension and is willing to process the REFER transaction without establishing an = implicit subscription, it MUST insert the "Refer-Sub" header = field set to "false" in the 2xx response to the REFER-Issuer.&nbs= p;

 

The key words here are= “and is WILLING to process the REFER transaction without establishin= g an implicit subscription” so there is always the possibility that a= subscription will be created even if norefersub is supported and Refer-Sub header field is set to FALSE.

 

However RFC 5057 seems to be in conflict with RFC 44= 88 in this regard stating:

 

 

   Dialogs with m= ultiple usages arise when a usage-creating action

   occurs inside = an existing dialog.  Such actions include accepting a

   REFER or SUBSC= RIBE issued inside a dialog established with an INVITE

   request. = Multiple REFERs within a dialog create multiple

   subscriptions,= each of which is a new dialog usage sharing common

   dialog state.&= nbsp; (Note that any REFER issued utilizing the

   subscriptio= n-suppression mechanism specified in [2] creates no new

   usage.)  Similarly, an endpoint in a dialog e= stablished with an

   INVITE might s= ubscribe to its peer's Key Press Markup Language (KPML)

   [3] and later = issue a REFER, resulting in three dialog usages sharing

   common dialog = state.

 

 

So the first question is if an RFC 6665 compliant UA= indicated either Require: norefersub or knows that the REFER recipient sup= ports norefersub and also indicates Refer-Sub: False in the REFER request &= nbsp;can that REFER request be sent on a dialog created by another Method (in the safe knowledge that no subscrip= tion will be created)?

 

If the answer to the first question is no – an= implicit subscription could still be created.

 

Can some other knowledge that the REFER recipient wi= ll not create an implicit subscription - such as the definition in another = specification outside of IETF of a feature that mandates that no subscripti= on be created by the REFER recipient and the indication of the support of such a feature by the REFER recipient= in a global tree media feature tag has been received by the REFER sender. = Does this allow an RFC 6665 UA to send the REFER on a dialog created by ano= ther Method?

 

I have discussed the issue with Adam Roach offline a= nd his view and mine is that RFC 6665 UAs do not send REFER requests sent o= n a dialog created by another Method except for interoperability with UAs t= hat don’t support GRUU and RFC 6665.

 

What is the view of the rest of the community?<= /o:p>

 

Andrew

---------------------------------------------------------------------
Th= is transmission (including any attachments) may contain confidential inform= ation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information= . Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immed= iately reply to the sender and delete this information from your system. Us= e, dissemination, distribution, or reproduction of this transmission by uni= ntended recipients is not authorized and may be unlawful.
--_000_BBF5DDFE515C3946BC18D733B20DAD2338E40340XMB104ADSrimnet_-- From oej@edvina.net Tue Oct 29 10:42:56 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C4A11E8185 for ; Tue, 29 Oct 2013 10:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAZbvt1tDeiT for ; Tue, 29 Oct 2013 10:42:55 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA8421F9D87 for ; Tue, 29 Oct 2013 10:42:41 -0700 (PDT) Received: from [192.168.40.22] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 0810C93C2A2; Tue, 29 Oct 2013 17:42:38 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_692B1506-4A8F-4F6E-941D-8C04136B950E"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: "Olle E. Johansson" In-Reply-To: <526FEACB.1000202@alum.mit.edu> Date: Tue, 29 Oct 2013 18:42:37 +0100 Message-Id: References: <5266E8EE.5060609@nostrum.com> <526FE67B.80400@bell-labs.com> <526FEACB.1000202@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1816) Cc: SIPCORE WG , Olle E Johanson Subject: Re: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 17:42:57 -0000 --Apple-Mail=_692B1506-4A8F-4F6E-941D-8C04136B950E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 Oct 2013, at 18:05, Paul Kyzivat wrote: > Vijay, >=20 > IMO we have now seen enough support to justify some sort of work item. >=20 > One thing we need to decide is how broadly to scope the work item. > We could try to scope it as narrowly as possible - about how a dual = stack server should deal with SIP URIs containing domain names. Or we = could scope it more broadly to clarifying all the aspects of mixing IPv4 = and IPv6 usage in SIP. >=20 > I'd be interested in hearing opinions about that. In the SIP Forum IPv6 wg the next item would be how to set up = connections after we have found the A and AAAA addresses. That will be a = separate draft - a happy eyeballs for SIP signalling. I guess some = people remember my questions about Happy Eyeballs for UDP at the Berlin = meeting ;-) I must have misread RFC 6157 earlier and will need to re-read it thanks = to Vijay's response, but there will be more work ahead after this DNS = item is resolved.=20 Personally I don't understand Cullen's objection to updating RFC 3263, = but that's something we need to discuss after the decision about this = being a workgroup item. I am still learning about IETF and RFC formalia = ;-) /O >=20 > Thanks, > Paul >=20 > On 10/29/13 12:46 PM, Vijay K. Gurbani wrote: >> On 10/22/2013 04:06 PM, Adam Roach wrote: >>> [as chair] >>>=20 >>> It has been brought to our attention that there might be some = confusion >>> about the status of and venue for discussing the >>> draft-johansson-sip-dual-stack document. >>>=20 >>> The SIPCORE chairs, together with our Area Director and the DISPATCH >>> chairs, have determined that the proper working group for this work, = if >>> it proceeds, is SIPCORE. That said, we have not yet heard enough = from >>> the community to yet determine whether to add a deliverable to the >>> SIPCORE charter for IPv4/IPv6 interactions. >>>=20 >>> So, the first step here is to determine whether there's enough = interest >>> to add a milestone for updating or clarifying RFC 3263 procedures = when >>> both A and AAAA records exist for a single authority. >>=20 >> Adam: I am not averse to adopting this work but do want to point out >> that it may end up impacting more than rfc3263. >>=20 >> Contrary to what draft-johansson-sip-dual-stack states, rfc6157 also >> deals with the signaling aspects of dual-stack SIP entities (see >> S3 of rfc6157). >>=20 >> The recommendation in rfc6157 is for autonomous systems to deploy = dual- >> stack servers or both IPv4-only and IPv6-only and populate DNS with >> A and AAAA RRs. My understanding is that = draft-johansson-sip-dual-stack >> does not obviate these recommendations but rather adds an additional >> requirement that DNS be populated such that a certain address family >> is preferred. >>=20 >> So, as we grapple with where to do this work, it may be that it = touches >> more than rfc3263 and may impact rfc6157 as well. We do not want to >> end up in a situation where there are multiple drafts specifying = dual- >> stack behaviour. >>=20 >> I don't know whether it makes sense for = draft-johansson-sip-dual-stack >> to update S3 of rfc6157, but note that rfc6157 does not update = rfc3263. >>=20 >> Thanks, >>=20 >> - vijay >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_692B1506-4A8F-4F6E-941D-8C04136B950E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1TCCBdEw ggO5oAMCAQICAwzF9zANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMzAxMjYxMjM0MjlaFw0x NTAxMjYxMjM0MjlaMHExFzAVBgNVBAMTDk9sbGUgSm9oYW5zc29uMR0wGwYJKoZIhvcNAQkBFg5v ZWpAZWR2aW5hLm5ldDE3MDUGCSqGSIb3DQEJARYoMDc2ZGY1NDBkZGJiMmJkNTliNTUxYTRjZWY5 MjE4NmQzNjNkYmIyNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmqasMHgkaLk5k0 wLfHa8L3ICewso+Sf8NWodzRroWD3GGT94T70v5qTYlXMs7K3H0kFGvKmk4JGPa+TbDptfcjicqY 9PGGB9ILQQ02jP8lvm1QJuDKrXoZ70C5ApW8dy4fjVmy4iDWugDeEYXRzvuSS3H7ygFzPFAOX80q r2pUzn/uRw4ui7EPp0g3nv1wfpVQ65zKYiy28Xzuvut8S3o9BsWPq9zCzfes2jJrKoMnyKDodmBD 3QZaCxPplmLKoW/7QylznhdI5H1xBWoMRvUAvdxY7bucwcDzChxGXzhrbtov2qz/CHV4UqBxdLmJ 4absg9wIk09IaWgThoe3d5MCAwEAAaOCAWgwggFkMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgEN BEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0 cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNVHSUEOTA3BggrBgEFBQcDBAYI KwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQm MCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2VydC5vcmcwMQYDVR0fBCowKDAmoCSgIoYg aHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwQwYDVR0RBDwwOoEOb2VqQGVkdmluYS5u ZXSBKDA3NmRmNTQwZGRiYjJiZDU5YjU1MWE0Y2VmOTIxODZkMzYzZGJiMjUwDQYJKoZIhvcNAQEF BQADggIBACp/GHgzobsgkZc2IHN7cZO/WF75ykiH+DMS7MkOXqjZCYBsyNT++TZ1n9Fs8fO75c0b UD5Yr4uM8j8z/1JzASqYMNZhmCAsAHvbyEEOJhtjBJhmSFUI+k1UWcK5SQ+FBsgF/RN39RTOKNaP sr3pUVRF0aC9DxmPgx4Duv5k7IMPEJKcBmTd2775/MPJRwQqyCIlaBPHlIjxG1yM+Z0hBIXYBW4F +s9GbYsIuvd5MqgM2Vkak1hqBkV7+jkb3EOC0L1sA8ZpjszUbeX0bwojTBx1nA79+ijtKN98gH4y EcLWbgW9b6OX//LltaXNBCGVv66OCLE5zwsOhSkjq1S8oHwBc+li3cSIfwYwYbWGBb2fUfKtPOT1 1fuBz+V2v2pChCDLF8e0LnY2i9SfuQxWtpgDXlR2+1GiXjM3BozlWtP1ske+II470nDziiPx2AYF aVKFwfaCcGT/eVHnNVgvYYDcL5n5oiP3ZvORsrnQQOZfzQ9m0A6cZMkB7eQ3muODPp6S3ghR6Ghb +qSB2PdjvQXg/nkZeVd4vlIpXK0gC0hdnG/+jkj3Dvepf1Bqodh5XqgbBgP4n8yeyPyuj+sXCaGU szESHQw+s8Xgy4/xnBL0PG7a7WeJ9J5Py4udrDP/cp2mNsjX5Gp4UvCdJ5ciMwqxwwcHgIbTJDyn 1kz/dIKyMYIDMzCCAy8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDov L3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJ KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwzF9zAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzEwMjkxNzQyMzhaMCMGCSqGSIb3 DQEJBDEWBBRMnVJXAzqMFFUXskOqzzS46XvwlDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3Jn AgMMxfcwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsT FWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0 eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMxfcwDQYJKoZIhvcNAQEBBQAE ggEAAa9GnjsGRFUaOt5Y+hdWA4/WQh+ZH9ktvw3U2LhaOF3oNqAxEhmsviyRnp60u7vQb3hN8qKz dIfM6Vy0Zy+B8GTR6AfgwCirP0KpVunIBDvB/Wv6BtWw7lgv0u72J3sPcSwaEu915aagAD9yl433 +w/5NZqD36rY5V6P4MUKt0E3F03yQQGRcZE987JDLY3CxR6hd/ZrV3wtVyYPxzcWbOB69Y05nod8 kCd1bFdOIwHZiamPhZtAFox9s7sRTWdQzxVywE60XMmspf+7ad+NKiXDrY3aJiM76loj14NemwQX ewAbhWtEN5BbgrQk2ay6dYtqM6lPD23zMjven231ngAAAAAAAA== --Apple-Mail=_692B1506-4A8F-4F6E-941D-8C04136B950E-- From vkg@bell-labs.com Tue Oct 29 10:52:55 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B356B21F9DFC for ; Tue, 29 Oct 2013 10:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPkU9C8HD5wa for ; Tue, 29 Oct 2013 10:52:41 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0D84F21F9F08 for ; Tue, 29 Oct 2013 10:52:26 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9THqJ76023756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Oct 2013 12:52:19 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r9THqIfx004724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Oct 2013 12:52:18 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r9THqId6008413; Tue, 29 Oct 2013 12:52:18 -0500 (CDT) Message-ID: <526FF5C3.8010404@bell-labs.com> Date: Tue, 29 Oct 2013 12:52:03 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: "pkyzivat@alum.mit.edu" References: <5266E8EE.5060609@nostrum.com> <526FE67B.80400@bell-labs.com> <526FEACB.1000202@alum.mit.edu> In-Reply-To: <526FEACB.1000202@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 17:52:55 -0000 On 10/29/2013 12:05 PM, Paul Kyzivat wrote: > Vijay, > > IMO we have now seen enough support to justify some sort of work item. Paul: Yes, absolutely. > One thing we need to decide is how broadly to scope the work item. > We could try to scope it as narrowly as possible - about how a dual > stack server should deal with SIP URIs containing domain names. Or we > could scope it more broadly to clarifying all the aspects of mixing IPv4 > and IPv6 usage in SIP. > > I'd be interested in hearing opinions about that. As I said in my previous email, it seems to me after reading draft-johansson-sip-dual-stack that it adds an additional recommendation to rfc6157 to convey address family preference via DNS for signaling. rfc6157 already prescribes that for media, both IPv6 and IPv4 addresses should be gathered and used in ICE. But it is clear, at least from the SIPit 29 [1], that the user agents are not doing so. Right now, handling dual-stack servers is straddled across rfc3263 and rfc6157. At the very least, when we go down the path of adding a work item, we should scope it such that the normative and informative knowledge around SIP in dual-stack environments, for both media and signaling, is contained in one document. I'd be happy to contribute to this. [1] https://www.sipit.net/SIPit29_summary Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From christer.holmberg@ericsson.com Tue Oct 29 11:06:28 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F33E21F9FF9 for ; Tue, 29 Oct 2013 11:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.961 X-Spam-Level: X-Spam-Status: No, score=-4.961 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQuMxZQWLZI7 for ; Tue, 29 Oct 2013 11:05:56 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7C95F21E809C for ; Tue, 29 Oct 2013 11:02:50 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-a9-526ff8432d2a Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E0.6D.16099.348FF625; Tue, 29 Oct 2013 19:02:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 19:02:43 +0100 From: Christer Holmberg To: Paul Kyzivat , Andrew Allen , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUqRBKqAf4v0eC21ZkCIO4WJoKgpMAgADN42CAAGCwgIAABKkAgAAcNdiAAAFRf///+uuAgAANRoCAAAgFgIAAGm/w Date: Tue, 29 Oct 2013 18:02:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4FAD82@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> , <526FC944.6090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4FAAAA@ESESSMB209.ericsson.se> <526FDDC5.6050201@alum.mit.edu> <526FEFA1.2070409@alum.mit.edu> In-Reply-To: <526FEFA1.2070409@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvja7Lj/wggwOmFvfnbWW0WLHhAKvF 1x+b2ByYPf6+/8DkMathLbvHkiU/mQKYo7hsUlJzMstSi/TtErgy5n7kL1jpVrHrxyLmBsaX Fl2MnBwSAiYS816tZ4awxSQu3FvP1sXIxSEkcIhR4tvb44wQzhJGiTdN15m6GDk42AQsJLr/ aYM0iAiUS3z5d50FxBYWSJS40NDHChFPkvi74jobhJ0nseZzD1gNi4CqROv0hWA2r4CvxKZJ kxlBbCGBJ2wST44agdicAjoSk56+A6thBDro+6k1TCA2s4C4xIeD16EOFZBYsuc8lC0q8fLx P1YIW0micckTVoh6PYkbU6ewQdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCy rGJkz03MzEkvN9zECIyNg1t+6+5gPHVO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmp xYcYmTg4pRoYMzZcn5M2Ry7slFxL29q8bwzp3C8jIhVfy7refbBXauXUkKsB7vmeopfKU603 vmCNkUmetmzhx32rohtWWE+ZPzfrCzufuP4F0eM/T97Ve//rkkPolvwWW31lP8dPxhqHH+WL V+38bCYrKfKoW3ariq6KalbCpHVz5fIY/jP90i4o37XurwWHEktxRqKhFnNRcSIA382CMVsC AAA= Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:06:30 -0000 Hi, In a Contact header field, the URI is a header field parameter, and any med= ia feature tag is by definition associated with that URI. In Feature-Caps, we don't have such "header field level" URI. If you define= a URI value for a FCI, that URI is by default only associated with that FC= I. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 L=E4hetetty: 29. lokakuuta 2013 19:26 Vastaanottaja: Andrew Allen; Christer Holmberg; sipcore@ietf.org Aihe: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tr= ee-cap-indicators On 10/29/13 12:57 PM, Andrew Allen wrote: > > Do we agree that if a UA indicates it supports a SIP Method or a SIP exte= nsion or a SIP event package then that UA supports that SIP Method or that = SIP extension or that SIP event package? Are you are asking this in the context of 3840? This seems appropriate. But "supports" is a bit slippery. I think we should be able to assume that support was there at the time the = indication was made. But it won't necessarily remain true forever.=20 And there is no specification of a minimum time that it must remain valid. Also, "support" also can be nuanced in other ways. For instance isFocus may= be true for certain dialogs and not others. So the knowledge imparted by these is "fuzzy". > If that same UA also indicates a URI that it can be reached at then that = UA that can be reached at the advertised URI also supports that SIP Method = or that SIP extension or that SIP event package - agree? In the context of 3840, yes. (Given the caveats above.) > So to me the issue to clarify in the global tree FCI that advertises the = URI is whether the URI is hosted by the same UA that also indicates the SIP= capabilities in the SIP tree FCIs. > > Does that make sense? I guess this would be an alternative approach to the one Christer suggested= . IIUC, you are saying that the definition of g.xxx.foo might say: - the server posting this FC is a foo server - the server posting this FC is reachable out of dialog at the supplied URI And then the FCI sip.x tag descriptions would say that they describe capabi= lities of the server posting the FC entry. This seems a little weird, but it might fly. I'd like to hear what other pe= ople think. Thanks, Paul > Andrew > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, October 29, 2013 12:10 PM > To: Christer Holmberg; Andrew Allen; sipcore@ietf.org > Subject: Re: [sipcore] New sipcore draft submission=20 > draft-allen-sipcore-sip-tree-cap-indicators > > Christer, > > What you say below seems plausible as a way forward. > > It does present a potential problem: > > Suppose you do that. And then another tag g.xxx.foo is defined with a URI= that identifies a foo server and a rule that says the presence or absence = of +sip.audio and +sip.video indicates whether the foo server at the URI su= pports audio and video. > > Then another tag g.xxx.bar is defined with a URI that identifies a bar=20 > server and a rule that says the presence or absence of +sip.audio and > +sip.video indicates whether the foo server at the URI supports audio > and video. > > Then something inserts a Feature-Caps entry. It wants to indicate a=20 > foo server that supports audio, and a bar server that supports video.=20 > It can't do that in a single entry. It could emit two entries as=20 > Andrew suggested. Is that valid? > > I think it will be necessary to spell out the rules for this sort of=20 > usage. And this won't necessarily be just for these tags in the sip=20 > tree. It could apply to other tags as well. If feels more like an=20 > extension (or maybe just a clarification) of 6809. > > Thanks, > Paul > > On 10/29/13 11:27 AM, Christer Holmberg wrote: >> Hi, >> >>> I would appreciate if the two of you would go off and come up with a=20 >>> proposal that you both agree is consistent with the language and=20 >>> intent of RFC 6809. >>> >>> What Christer is suggesting *might* work, though I reserve judgement=20 >>> until I see that actual language that you settle on. If you go that=20 >>> way, then I want to see an explanation of how the sip tree tags are spe= cified. >> I think we would have to say that the sip.x FCIs as such don't=20 >> provide much information. Instead, they can be used together with=20 >> OTHER FCIs, to provide additional information about those OTHER FCIs.=20 >> But, the FCI specifcation of such OTHER FCI MUST describe which sip.x=20 >> FCIs are used to provide additional information, and how. >> Regards, >> Chrsiter >> >> On 10/29/13 10:25 AM, Andrew Allen wrote: >>> Christer >>> >>> My responses inline >>> >>> Andrew >>> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Tuesday, October 29, 2013 3:48 AM >>> To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org >>> Subject: RE: [sipcore] New sipcore draft submission=20 >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> Hi, >>> >>>> In actual usage many feature capability indicators (FCIs) are being=20 >>>> used to communicate URIs. The ones that communicate URIs listed=20 >>>> below are just from one 3GPP 3GPP specification (and there are=20 >>>> several other specifications that define feature capability=20 >>>> indicators) and many of these FCIs were defined by the authors of=20 >>>> RFC 6809. So I think it has been found to be necessary to=20 >>>> communicate URIs in FCIs. Usually these URIs are used as the=20 >>>> Request-URI of a SIP >> request and the URI is hosted by the server that included the FCI. >>>> >>>> If a UA indicates a URI hosted by it and a UA also indicates=20 >>>> certain capabilities such as he supported SIP methods and SIP=20 >>>> extensions I think you can infer that the UA supports those methods=20 >>>> and extensions and the UA can be contacted at the URI. When=20 >>>> contacting the UA at the indicated URI it seems to me to be a=20 >>>> reasonable assumption to make that the methods and extensions also=20 >>>> indicated are >> going to be supported. >>>> >>>> If the physical entity inserting the FCIs has different URIs that=20 >>>> represent logically different UAs (with different SIP methods and exte= nsions supported) then the different logical UAs and their associated capab= ilities should be indicated in different Feature-Caps header fields. >>> >>> Again, I don't think one should make such "default assumption". >>> >>> Instead, the g.xxx.yyy FCI specification needs to explicitly say that, = when used in conjunction with the sip.methods FCI, the sip.methods FCI indi= cates which SIP methods can be used when using the URI provided by the g.xx= x.yyy FCI. >>> >>> [AA] I am OK to go the approach that we state whether the scope of the = FCI (and the URI value of the FCI) is such that other FCIs in the SIP tree = include in the same header field apply to that URI or not. >>> >>> (Of course, the g.xxx.yyy FCI specification itself can also define whic= h SIP methods can be used, if the allowed methods are always the same, in w= hich case there is no need for sip.methods). >>> >>> [AA] I am not happy with that approach - I think that is "hidden magic"= that some feature outside of SIP is defining what SIP features are suppor= ted. >>> >>> Regards, >>> >>> Christer >>> -------------------------------------------------------------------- >>> - This transmission (including any attachments) may contain=20 >>> confidential information, privileged material (including material=20 >>> protected by the solicitor-client or other applicable privileges),=20 >>> or constitute non-public information. Any use of this information =20 >>> by anyone other than the intended recipient is prohibited. If you=20 >>> have >> received this transmission in error, please immediately reply to the=20 >> sender and delete this information from your system. Use,=20 >> dissemination, distribution, or reproduction of this transmission by=20 >> unintended recipients is not authorized and may be unlawful. >>> >>> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > > From gsalguei@cisco.com Tue Oct 29 11:09:16 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2999611E8185 for ; Tue, 29 Oct 2013 11:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUo7ipNCsNWB for ; Tue, 29 Oct 2013 11:09:12 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C1D8C11E8240 for ; Tue, 29 Oct 2013 11:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2307; q=dns/txt; s=iport; t=1383069989; x=1384279589; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bwjsNJ3g9cn8dO1ez/x5fHc5b1Q2pDXlandQZCYqlQc=; b=U0rS20Ck6gSo+E7RLw1ee1VemXuCj+7mDPjveHJgip8Cxz1aImE9J/SS Tc9kj1xTMYiBDrDkKW7Twz91R9e2HE+7G6OSZAUb00+QQpi/lv7cuzSo6 iROGaxNyLgjwDp8Y5cDWXFDtaSLN7Wv5hZ8DP//Ls9EdXcqRFf3E12aLV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFACn4b1KtJV2c/2dsb2JhbABZgwc4Tga+aUuBLBZ0giUBAQEDAQEBATc0CwULAgEIGAoUECcLJQIEDgUIh3kGCAW6LI1+gRYCMQeDH4ENA6ReAYUzgyZxAQF+OQ X-IronPort-AV: E=Sophos;i="4.93,594,1378857600"; d="scan'208";a="278188625" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 29 Oct 2013 18:06:17 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9TI6HNI005401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 18:06:17 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 13:06:17 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Vijay K. Gurbani" Thread-Topic: [sipcore] draft-johansson-sip-dual-stack Thread-Index: AQHOz2qzI4jONYz/JU+WCT5IOHuUfpoMQeqAgAAFJICAAA0UgIAAA/qA Date: Tue, 29 Oct 2013 18:06:17 +0000 Message-ID: References: <5266E8EE.5060609@nostrum.com> <526FE67B.80400@bell-labs.com> <526FEACB.1000202@alum.mit.edu> <526FF5C3.8010404@bell-labs.com> In-Reply-To: <526FF5C3.8010404@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.55] Content-Type: text/plain; charset="us-ascii" Content-ID: <8B831B36AC05054DB598FBA56F8D51A6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-johansson-sip-dual-stack X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:09:16 -0000 On Oct 29, 2013, at 1:52 PM, Vijay K. Gurbani wrote: > On 10/29/2013 12:05 PM, Paul Kyzivat wrote: >> Vijay, >>=20 >> IMO we have now seen enough support to justify some sort of work item. >=20 > Paul: Yes, absolutely. >=20 >> One thing we need to decide is how broadly to scope the work item. >> We could try to scope it as narrowly as possible - about how a dual >> stack server should deal with SIP URIs containing domain names. Or we >> could scope it more broadly to clarifying all the aspects of mixing IPv4 >> and IPv6 usage in SIP. >>=20 >> I'd be interested in hearing opinions about that. >=20 > As I said in my previous email, it seems to me after reading draft-johans= son-sip-dual-stack that it adds an additional recommendation > to rfc6157 to convey address family preference via DNS for signaling. > rfc6157 already prescribes that for media, both IPv6 and IPv4 addresses > should be gathered and used in ICE. But it is clear, at least from > the SIPit 29 [1], that the user agents are not doing so. >=20 > Right now, handling dual-stack servers is straddled across rfc3263 and > rfc6157. At the very least, when we go down the path of adding a work it= em, we should scope it such that the normative and informative > knowledge around SIP in dual-stack environments, for both media and > signaling, is contained in one document. The original scope of the draft was centered around updating 3263 and kept = intentionally narrow. Vijay's comments make sense and my interpretation of= their impact is that perhaps the update of 6157 would be a reasonably mana= geable addition without making the scope a massive multi-year project. >=20 > I'd be happy to contribute to this. We'd appreciate it. Cheers, Gonzalo >=20 > [1] https://www.sipit.net/SIPit29_summary >=20 > Thanks, >=20 > - vijay > --=20 > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From aallen@blackberry.com Tue Oct 29 11:16:41 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00A711E8110 for ; Tue, 29 Oct 2013 11:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WYUEkBGGM2k for ; Tue, 29 Oct 2013 11:16:29 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC4F11E818E for ; Tue, 29 Oct 2013 11:16:20 -0700 (PDT) Received: from xct105ads.rim.net ([10.67.111.46]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 29 Oct 2013 14:16:13 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.03.0123.003; Tue, 29 Oct 2013 13:16:13 -0500 From: Andrew Allen To: "christer.holmberg@ericsson.com" , "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUo+ZAiuycmUumaJncVjjxK5oKi8CQgAEa1ICAABo8MIAAWZQAgAAMwoCAAAuwgP//t/4QgABdTICAAApJAP//r/VD Date: Tue, 29 Oct 2013 18:16:12 +0000 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4FAD82@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:16:42 -0000 However if the FCI defines that the URI is hosted by the entity that insert= ed it and the sip tree FCIs are also defined as being scoped to the entity = that inserted them then they would be associated. While an entity might indicate an FCI containing a URI not hosted by it I t= hink it problematic for items from the SIP tree to be indicated on behalf o= f other entities as this would require quite detailed knowledge of the impl= ementations of other entities and could change when ever software is update= d on the other entity. E.G. A service proxy may well be aware (by configura= tion) that server foo supports foobar feature and that the foobar feature c= an be reached at sip:foobar.example.com;gr but the service proxy is unlikel= y to have reliable up to date information about all the SIP methods, SIP ex= tensions and SIP event packages supported by foo nor what the media capabil= ities of foo are. Andrew ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, October 29, 2013 01:02 PM Central Standard Time To: Paul Kyzivat ; Andrew Allen; sipcore@ietf.org Subject: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators Hi, In a Contact header field, the URI is a header field parameter, and any med= ia feature tag is by definition associated with that URI. In Feature-Caps, we don't have such "header field level" URI. If you define= a URI value for a FCI, that URI is by default only associated with that FC= I. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] = L=E4hetetty: 29. lokakuuta 2013 19:26 Vastaanottaja: Andrew Allen; Christer Holmberg; sipcore@ietf.org Aihe: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tr= ee-cap-indicators On 10/29/13 12:57 PM, Andrew Allen wrote: > > Do we agree that if a UA indicates it supports a SIP Method or a SIP exte= nsion or a SIP event package then that UA supports that SIP Method or that = SIP extension or that SIP event package? Are you are asking this in the context of 3840? This seems appropriate. But "supports" is a bit slippery. I think we should be able to assume that support was there at the time the = indication was made. But it won't necessarily remain true forever. = And there is no specification of a minimum time that it must remain valid. Also, "support" also can be nuanced in other ways. For instance isFocus may= be true for certain dialogs and not others. So the knowledge imparted by these is "fuzzy". > If that same UA also indicates a URI that it can be reached at then that = UA that can be reached at the advertised URI also supports that SIP Method = or that SIP extension or that SIP event package - agree? In the context of 3840, yes. (Given the caveats above.) > So to me the issue to clarify in the global tree FCI that advertises the = URI is whether the URI is hosted by the same UA that also indicates the SIP= capabilities in the SIP tree FCIs. > > Does that make sense? I guess this would be an alternative approach to the one Christer suggested. IIUC, you are saying that the definition of g.xxx.foo might say: - the server posting this FC is a foo server - the server posting this FC is reachable out of dialog at the supplied URI And then the FCI sip.x tag descriptions would say that they describe capabi= lities of the server posting the FC entry. This seems a little weird, but it might fly. I'd like to hear what other pe= ople think. Thanks, Paul > Andrew > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, October 29, 2013 12:10 PM > To: Christer Holmberg; Andrew Allen; sipcore@ietf.org > Subject: Re: [sipcore] New sipcore draft submission = > draft-allen-sipcore-sip-tree-cap-indicators > > Christer, > > What you say below seems plausible as a way forward. > > It does present a potential problem: > > Suppose you do that. And then another tag g.xxx.foo is defined with a URI= that identifies a foo server and a rule that says the presence or absence = of +sip.audio and +sip.video indicates whether the foo server at the URI su= pports audio and video. > > Then another tag g.xxx.bar is defined with a URI that identifies a bar = > server and a rule that says the presence or absence of +sip.audio and > +sip.video indicates whether the foo server at the URI supports audio > and video. > > Then something inserts a Feature-Caps entry. It wants to indicate a = > foo server that supports audio, and a bar server that supports video. = > It can't do that in a single entry. It could emit two entries as = > Andrew suggested. Is that valid? > > I think it will be necessary to spell out the rules for this sort of = > usage. And this won't necessarily be just for these tags in the sip = > tree. It could apply to other tags as well. If feels more like an = > extension (or maybe just a clarification) of 6809. > > Thanks, > Paul > > On 10/29/13 11:27 AM, Christer Holmberg wrote: >> Hi, >> >>> I would appreciate if the two of you would go off and come up with a = >>> proposal that you both agree is consistent with the language and = >>> intent of RFC 6809. >>> >>> What Christer is suggesting *might* work, though I reserve judgement = >>> until I see that actual language that you settle on. If you go that = >>> way, then I want to see an explanation of how the sip tree tags are spe= cified. >> I think we would have to say that the sip.x FCIs as such don't = >> provide much information. Instead, they can be used together with = >> OTHER FCIs, to provide additional information about those OTHER FCIs. = >> But, the FCI specifcation of such OTHER FCI MUST describe which sip.x = >> FCIs are used to provide additional information, and how. >> Regards, >> Chrsiter >> >> On 10/29/13 10:25 AM, Andrew Allen wrote: >>> Christer >>> >>> My responses inline >>> >>> Andrew >>> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Tuesday, October 29, 2013 3:48 AM >>> To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org >>> Subject: RE: [sipcore] New sipcore draft submission = >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> Hi, >>> >>>> In actual usage many feature capability indicators (FCIs) are being = >>>> used to communicate URIs. The ones that communicate URIs listed = >>>> below are just from one 3GPP 3GPP specification (and there are = >>>> several other specifications that define feature capability = >>>> indicators) and many of these FCIs were defined by the authors of = >>>> RFC 6809. So I think it has been found to be necessary to = >>>> communicate URIs in FCIs. Usually these URIs are used as the = >>>> Request-URI of a SIP >> request and the URI is hosted by the server that included the FCI. >>>> >>>> If a UA indicates a URI hosted by it and a UA also indicates = >>>> certain capabilities such as he supported SIP methods and SIP = >>>> extensions I think you can infer that the UA supports those methods = >>>> and extensions and the UA can be contacted at the URI. When = >>>> contacting the UA at the indicated URI it seems to me to be a = >>>> reasonable assumption to make that the methods and extensions also = >>>> indicated are >> going to be supported. >>>> >>>> If the physical entity inserting the FCIs has different URIs that = >>>> represent logically different UAs (with different SIP methods and exte= nsions supported) then the different logical UAs and their associated capab= ilities should be indicated in different Feature-Caps header fields. >>> >>> Again, I don't think one should make such "default assumption". >>> >>> Instead, the g.xxx.yyy FCI specification needs to explicitly say that, = when used in conjunction with the sip.methods FCI, the sip.methods FCI indi= cates which SIP methods can be used when using the URI provided by the g.xx= x.yyy FCI. >>> >>> [AA] I am OK to go the approach that we state whether the scope of the = FCI (and the URI value of the FCI) is such that other FCIs in the SIP tree = include in the same header field apply to that URI or not. >>> >>> (Of course, the g.xxx.yyy FCI specification itself can also define whic= h SIP methods can be used, if the allowed methods are always the same, in w= hich case there is no need for sip.methods). >>> >>> [AA] I am not happy with that approach - I think that is "hidden magic"= that some feature outside of SIP is defining what SIP features are suppor= ted. >>> >>> Regards, >>> >>> Christer >>> -------------------------------------------------------------------- >>> - This transmission (including any attachments) may contain = >>> confidential information, privileged material (including material = >>> protected by the solicitor-client or other applicable privileges), = >>> or constitute non-public information. Any use of this information = >>> by anyone other than the intended recipient is prohibited. If you = >>> have >> received this transmission in error, please immediately reply to the = >> sender and delete this information from your system. Use, = >> dissemination, distribution, or reproduction of this transmission by = >> unintended recipients is not authorized and may be unlawful. >>> >>> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Tue Oct 29 11:20:31 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE0011E818E for ; Tue, 29 Oct 2013 11:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.961 X-Spam-Level: X-Spam-Status: No, score=-4.961 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_31=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Mk+NYZonLKD for ; Tue, 29 Oct 2013 11:20:24 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CB08E11E8185 for ; Tue, 29 Oct 2013 11:20:23 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-05-526ffc66c343 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E3.D8.03802.66CFF625; Tue, 29 Oct 2013 19:20:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 19:20:22 +0100 From: Christer Holmberg To: Paul Kyzivat , Andrew Allen , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUqRBKqAf4v0eC21ZkCIO4WJoKgpMAgADN42CAAGCwgIAABKkAgAAcNdiAAAFRf///+uuAgAAyGZA= Date: Tue, 29 Oct 2013 18:20:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4FADEA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> , <526FC944.6090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4FAAAA@ESESSMB209.ericsson.se> <526FDDC5.6050201@alum.mit.edu> In-Reply-To: <526FDDC5.6050201@alum.mit.edu> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvjW7an/wgg5ctShb3521ltFix4QCr xdcfm9gcmD3+vv/A5DGrYS27x5IlP5kCmKO4bFJSczLLUov07RK4Mm5/8yvoNqjovtTF0sB4 Xa2LkZNDQsBEomv7ZCYIW0ziwr31bF2MXBxCAocYJVa/WMUO4SxhlOj8Mw2oioODTcBCovuf NkiDiEC5xJd/11lAbGGBRIkLDX2sEPEkib8rrrPB2LPPQcRZBFQl5m17wwhi8wr4Ssz9NZ8V Yn4zm8SxxRPBruAU0JF4ceE1WAMj0EXfT60BizMLiEt8OHidGeJSAYkle85D2aISLx//Y4Ww lSQalzxhhajXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkb2 3MTMnPRyo02MwPg4uOW36g7GO+dEDjFKc7AoifN+eOscJCSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoFx67OAthJzzZyVs5/uyWqLL1jFduMc0wG9e30W7+2NbPVeyu0S5DknsHJOUqHI5w9/ 58WdXPdlD/8FrWUdMxc1ppQ3Bhhfyv/IvnyqcvwH1snObst99wlcWW46U9U/TiK28omk/LLX /RnRl+Q/sdiUvL98xKXQ69lJP7GbL90jF3AXKs/wm35AiaU4I9FQi7moOBEAIsVnTF0CAAA= Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:20:31 -0000 Hi, >What you say below seems plausible as a way forward. > >It does present a potential problem: > >Suppose you do that. And then another tag g.xxx.foo is defined with a URI = that identifies a foo server and a rule that says the presence or absence o= f +sip.audio and +sip.video indicates whether the foo server at the URI sup= ports audio and video. > >Then another tag g.xxx.bar is defined with a URI that identifies a bar ser= ver and a rule that says the presence or absence of +sip.audio and=20 >+sip.video indicates whether the foo server at the URI supports audio >and video. > >Then something inserts a Feature-Caps entry. It wants to indicate a foo=20 >server that supports audio, and a bar server that supports video. It=20 >can't do that in a single entry. It could emit two entries as Andrew=20 >suggested. Is that valid? In my opinion, yes. 6809 does not forbid an entity to insert more than one = F-C entry. Another alternative, of course, is to indicate the SIP methods (and/or what= ever other information associated with the FCI) as part of the FCI value it= self. Keep in mind that the FCI value can be a string value, so you can put= more or less whatever you want in it. Eg: Feature-Caps:*;+3gpp.xxx=3D"sip:blah@example.com:methods=3DINVITE,REFER" ...or something like that. Note, that in this case methods is not a URI par= ameter, it's just another part of the FCI string value (the syntax of the s= tring value is defined in the FCI specification). >I think it will be necessary to spell out the rules for this sort of=20 >usage. And this won't necessarily be just for these tags in the sip=20 >tree. It could apply to other tags as well. If feels more like an=20 >extension (or maybe just a clarification) of 6809. Perhaps we'll have to do that at some point. It's probably good to get some= implementation feedback from 3GPP (and others) first. Regards, Christer On 10/29/13 11:27 AM, Christer Holmberg wrote: > Hi, > >>I would appreciate if the two of you would go off and come up with a >>proposal that you both agree is consistent with the language and intent >>of RFC 6809. >> >>What Christer is suggesting *might* work, though I reserve judgement >>until I see that actual language that you settle on. If you go that way, >>then I want to see an explanation of how the sip tree tags are specified. > I think we would have to say that the sip.x FCIs as such don't provide > much information. Instead, they can be used together with OTHER FCIs, to > provide additional information about those OTHER FCIs. But, the FCI > specifcation of such OTHER FCI MUST describe which sip.x FCIs are used > to provide additional information, and how. > Regards, > Chrsiter > > On 10/29/13 10:25 AM, Andrew Allen wrote: >> Christer >> >> My responses inline >> >> Andrew >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Tuesday, October 29, 2013 3:48 AM >> To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org >> Subject: RE: [sipcore] New sipcore draft submission draft-allen-sipcore-= sip-tree-cap-indicators >> >> Hi, >> >>> In actual usage many feature capability indicators (FCIs) are being >>> used to communicate URIs. The ones that communicate URIs listed below >>> are just from one 3GPP 3GPP specification (and there are several other = specifications that define feature capability indicators) and many of these= FCIs were defined by the authors of RFC 6809. So I think it has been found= to be necessary to communicate URIs in FCIs. Usually these URIs are used = as the Request-URI of a SIP > request and the URI is hosted by the server that included the FCI. >>> >>> If a UA indicates a URI hosted by it and a UA also indicates certain >>> capabilities such as he supported SIP methods and SIP extensions I thin= k you can infer that the UA supports those methods and extensions and the U= A can be contacted at the URI. When contacting the UA at the indicated URI= it seems to me to be a reasonable assumption to make that the methods and= extensions also indicated are > going to be supported. >>> >>> If the physical entity inserting the FCIs has different URIs that >>> represent logically different UAs (with different SIP methods and exten= sions supported) then the different logical UAs and their associated capabi= lities should be indicated in different Feature-Caps header fields. >> >> Again, I don't think one should make such "default assumption". >> >> Instead, the g.xxx.yyy FCI specification needs to explicitly say that, w= hen used in conjunction with the sip.methods FCI, the sip.methods FCI indic= ates which SIP methods can be used when using the URI provided by the g.xxx= .yyy FCI. >> >> [AA] I am OK to go the approach that we state whether the scope of the F= CI (and the URI value of the FCI) is such that other FCIs in the SIP tree i= nclude in the same header field apply to that URI or not. >> >> (Of course, the g.xxx.yyy FCI specification itself can also define which= SIP methods can be used, if the allowed methods are always the same, in wh= ich case there is no need for sip.methods). >> >> [AA] I am not happy with that approach - I think that is "hidden magic" = that some feature outside of SIP is defining what SIP features are support= ed. >> >> Regards, >> >> Christer >> --------------------------------------------------------------------- >> This transmission (including any attachments) may contain confidential i= nformation, privileged material (including material protected by the solici= tor-client or other applicable privileges), or constitute non-public inform= ation. Any use of this information by anyone other than the intended recip= ient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, dissemination, > distribution, or reproduction of this transmission by unintended > recipients is not authorized and may be unlawful. >> >> > From christer.holmberg@ericsson.com Tue Oct 29 11:22:29 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9B411E8185 for ; Tue, 29 Oct 2013 11:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[AWL=-1.738, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htxT6Jq2fWWb for ; Tue, 29 Oct 2013 11:22:16 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2DB11E822E for ; Tue, 29 Oct 2013 11:22:14 -0700 (PDT) X-AuditID: c1b4fb38-b7f178e00000233b-9a-526ffcd4897a Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 87.B6.09019.4DCFF625; Tue, 29 Oct 2013 19:22:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 19:22:12 +0100 From: Christer Holmberg To: Andrew Allen , "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUqRBKqAf4v0eC21ZkCIO4WJoKgpMAgADN42CAAGCwgIAABKkAgAAcNdiAAAFRf///+uuAgAANRoCAAAgFgIAAGm/w///zoACAABIHMA== Date: Tue, 29 Oct 2013 18:22:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4FADFF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4FAD82@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvje7VP/lBBtsnclncn7eV0WLFhgOs Fl9/bGJzYPb4+/4Dk8eshrXsHkuW/GQKYI7isklJzcksSy3St0vgyuj8tIG14ENAxb8fO9gb GK85djFyckgImEj8/reCBcIWk7hwbz1bFyMXh5DAEUaJk78fMkI4Sxgl7izYyNrFyMHBJmAh 0f1PGyQuItDEKPHi/lo2kLiwQKrE878VIINEBNIkvrZfZYSw6yTe3pkFZrMIqEr0/zjIDGLz CvhKnG66yg4xv4dRYt2+fawgCU4BT4nOzrvsIDYj0EXfT61hArGZBcQlPhy8zgxxqYDEkj3n oWxRiZeP/7FC2EoSjUuesELU60ncmDqFDcLWlli28DXUYkGJkzOfsExgFJ2FZOwsJC2zkLTM QtKygJFlFSNHcWpxUm66kcEmRmCMHNzy22IH4+W/NocYpTlYlMR5P751DhISSE8sSc1OTS1I LYovKs1JLT7EyMTBKdXAqF0fe7XibaJpyfrPJfyWxeevTTgV/yjp4neXcL+5XTNPBb/aWbbX bPfER1NZHzq255ZmzeDfsGzG2clSzvvm5LxMiDz85MjZ9Hs6TN8sw5/kS6zccmHttHWGH406 N2cs/aUQFjjjp/Da/G6fp6vWbggv6/PbpP1U7LLL2rQWPqe7tW+fV95W/qzEUpyRaKjFXFSc CACbTio2XwIAAA== Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:22:29 -0000 Hi, >However if the FCI defines that the URI is hosted by the entity that inser= ted it and the sip tree FCIs are also defined as being scoped to the entity= that inserted them then they would be associated. Absolutely.=20 But, again, the FCI specification needs to explicitly define that :) Regards, Christer ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, October 29, 2013 01:02 PM Central Standard Time To: Paul Kyzivat ; Andrew Allen; sipcore@ietf.org Subject: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators Hi, In a Contact header field, the URI is a header field parameter, and any med= ia feature tag is by definition associated with that URI. In Feature-Caps, we don't have such "header field level" URI. If you define= a URI value for a FCI, that URI is by default only associated with that FC= I. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] L=E4hetetty: 29. lokakuuta 2013 19:26 Vastaanottaja: Andrew Allen; Christer Holmberg; sipcore@ietf.org Aihe: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tr= ee-cap-indicators On 10/29/13 12:57 PM, Andrew Allen wrote: > > Do we agree that if a UA indicates it supports a SIP Method or a SIP exte= nsion or a SIP event package then that UA supports that SIP Method or that = SIP extension or that SIP event package? Are you are asking this in the context of 3840? This seems appropriate. But "supports" is a bit slippery. I think we should be able to assume that support was there at the time the = indication was made. But it won't necessarily remain true forever.=20 And there is no specification of a minimum time that it must remain valid. Also, "support" also can be nuanced in other ways. For instance isFocus may= be true for certain dialogs and not others. So the knowledge imparted by these is "fuzzy". > If that same UA also indicates a URI that it can be reached at then that = UA that can be reached at the advertised URI also supports that SIP Method = or that SIP extension or that SIP event package - agree? In the context of 3840, yes. (Given the caveats above.) > So to me the issue to clarify in the global tree FCI that advertises the = URI is whether the URI is hosted by the same UA that also indicates the SIP= capabilities in the SIP tree FCIs. > > Does that make sense? I guess this would be an alternative approach to the one Christer suggested= . IIUC, you are saying that the definition of g.xxx.foo might say: - the server posting this FC is a foo server - the server posting this FC is reachable out of dialog at the supplied URI And then the FCI sip.x tag descriptions would say that they describe capabi= lities of the server posting the FC entry. This seems a little weird, but it might fly. I'd like to hear what other pe= ople think. Thanks, Paul > Andrew > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, October 29, 2013 12:10 PM > To: Christer Holmberg; Andrew Allen; sipcore@ietf.org > Subject: Re: [sipcore] New sipcore draft submission=20 > draft-allen-sipcore-sip-tree-cap-indicators > > Christer, > > What you say below seems plausible as a way forward. > > It does present a potential problem: > > Suppose you do that. And then another tag g.xxx.foo is defined with a URI= that identifies a foo server and a rule that says the presence or absence = of +sip.audio and +sip.video indicates whether the foo server at the URI su= pports audio and video. > > Then another tag g.xxx.bar is defined with a URI that identifies a bar=20 > server and a rule that says the presence or absence of +sip.audio and > +sip.video indicates whether the foo server at the URI supports audio > and video. > > Then something inserts a Feature-Caps entry. It wants to indicate a=20 > foo server that supports audio, and a bar server that supports video. > It can't do that in a single entry. It could emit two entries as=20 > Andrew suggested. Is that valid? > > I think it will be necessary to spell out the rules for this sort of=20 > usage. And this won't necessarily be just for these tags in the sip=20 > tree. It could apply to other tags as well. If feels more like an=20 > extension (or maybe just a clarification) of 6809. > > Thanks, > Paul > > On 10/29/13 11:27 AM, Christer Holmberg wrote: >> Hi, >> >>> I would appreciate if the two of you would go off and come up with a=20 >>> proposal that you both agree is consistent with the language and=20 >>> intent of RFC 6809. >>> >>> What Christer is suggesting *might* work, though I reserve judgement=20 >>> until I see that actual language that you settle on. If you go that=20 >>> way, then I want to see an explanation of how the sip tree tags are spe= cified. >> I think we would have to say that the sip.x FCIs as such don't=20 >> provide much information. Instead, they can be used together with=20 >> OTHER FCIs, to provide additional information about those OTHER FCIs. >> But, the FCI specifcation of such OTHER FCI MUST describe which sip.x=20 >> FCIs are used to provide additional information, and how. >> Regards, >> Chrsiter >> >> On 10/29/13 10:25 AM, Andrew Allen wrote: >>> Christer >>> >>> My responses inline >>> >>> Andrew >>> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Tuesday, October 29, 2013 3:48 AM >>> To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org >>> Subject: RE: [sipcore] New sipcore draft submission=20 >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> Hi, >>> >>>> In actual usage many feature capability indicators (FCIs) are being=20 >>>> used to communicate URIs. The ones that communicate URIs listed=20 >>>> below are just from one 3GPP 3GPP specification (and there are=20 >>>> several other specifications that define feature capability >>>> indicators) and many of these FCIs were defined by the authors of=20 >>>> RFC 6809. So I think it has been found to be necessary to=20 >>>> communicate URIs in FCIs. Usually these URIs are used as the=20 >>>> Request-URI of a SIP >> request and the URI is hosted by the server that included the FCI. >>>> >>>> If a UA indicates a URI hosted by it and a UA also indicates=20 >>>> certain capabilities such as he supported SIP methods and SIP=20 >>>> extensions I think you can infer that the UA supports those methods=20 >>>> and extensions and the UA can be contacted at the URI. When=20 >>>> contacting the UA at the indicated URI it seems to me to be a=20 >>>> reasonable assumption to make that the methods and extensions also=20 >>>> indicated are >> going to be supported. >>>> >>>> If the physical entity inserting the FCIs has different URIs that=20 >>>> represent logically different UAs (with different SIP methods and exte= nsions supported) then the different logical UAs and their associated capab= ilities should be indicated in different Feature-Caps header fields. >>> >>> Again, I don't think one should make such "default assumption". >>> >>> Instead, the g.xxx.yyy FCI specification needs to explicitly say that, = when used in conjunction with the sip.methods FCI, the sip.methods FCI indi= cates which SIP methods can be used when using the URI provided by the g.xx= x.yyy FCI. >>> >>> [AA] I am OK to go the approach that we state whether the scope of the = FCI (and the URI value of the FCI) is such that other FCIs in the SIP tree = include in the same header field apply to that URI or not. >>> >>> (Of course, the g.xxx.yyy FCI specification itself can also define whic= h SIP methods can be used, if the allowed methods are always the same, in w= hich case there is no need for sip.methods). >>> >>> [AA] I am not happy with that approach - I think that is "hidden magic"= that some feature outside of SIP is defining what SIP features are suppor= ted. >>> >>> Regards, >>> >>> Christer >>> -------------------------------------------------------------------- >>> - This transmission (including any attachments) may contain=20 >>> confidential information, privileged material (including material=20 >>> protected by the solicitor-client or other applicable privileges),=20 >>> or constitute non-public information. Any use of this information by=20 >>> anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the=20 >> sender and delete this information from your system. Use,=20 >> dissemination, distribution, or reproduction of this transmission by=20 >> unintended recipients is not authorized and may be unlawful. >>> >>> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Tue Oct 29 11:25:13 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C546611E8260 for ; Tue, 29 Oct 2013 11:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8laJh+r--3O for ; Tue, 29 Oct 2013 11:25:07 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4576B11E823C for ; Tue, 29 Oct 2013 11:25:06 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-f6-526ffd8125d6 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id ED.19.03802.18DFF625; Tue, 29 Oct 2013 19:25:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 19:25:05 +0100 From: Christer Holmberg To: Andrew Allen , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUqRBKqAf4v0eC21ZkCIO4WJoKgpMAgADN42CAAGCwgIAAUw+w Date: Tue, 29 Oct 2013 18:25:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4FAE19@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+JvjW7j3/wgg8enpS3uz9vKaLFiwwFW i68/NrE5MHv8ff+ByWNWw1p2jyVLfjIFMEdx2aSk5mSWpRbp2yVwZby90sRUcI614t6Dq4wN jJtZuhg5OSQETCTOT9jJDmGLSVy4t56ti5GLQ0jgEKPE/82bWCGcJYwSzy7vAXI4ONgELCS6 /2mDNIgIlEs8PnmYDcQWFkiUuNDQxwoRT5L4u+I6G0i5iICbRPPsdJAwi4CqxNlVF8B28Qr4 Svx9Owtq/F8WiZXHv4MdxCngKfHl7HZGEJsR6KDvp9YwgdjMAuISHw5eZ4Y4VEBiyZ7zULao xMvH/1ghbCWJxiVPWCHqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gmMIrOQjJ2FpKWWUhaZiFp WcDIsoqRPTcxMye93GgTIzA+Dm75rbqD8c45kUOM0hwsSuK8H946BwkJpCeWpGanphakFsUX leakFh9iZOLglGpgnHxljlZBPetcG6/Ku6UcpTbPN906zNPoMuNjouRvxSfc+VkvE1Z38ohc Vn6yOUT6/8PgMxEyerc1cpZ+uvP5ahTDC0/VCS18eq5eK/LYNLadqZU5vpk3ydqZ+5TNzzUa xrtY+rezdyZWdnO/7GLT/BSz9HZjvuKlJV1fVAz2BHw+XciYqlOpxFKckWioxVxUnAgAR2GE lV0CAAA= Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:25:14 -0000 > (Of course, the g.xxx.yyy FCI specification itself can also define which = SIP methods can be used, if the allowed methods are always the same, in whi= ch case there is no need for sip.methods).=20 > > [AA] I am not happy with that approach - I think that is "hidden magic" = that some feature outside of SIP is defining what SIP features are supporte= d. I am not sure what you understand. If a FCI specification says that the URI= value of the +g.xxx.yyy FCI can only be used for SIP method X, I don't see= that as hidden magic. Keep in mind that, unlike media feature tags, usage of feature-capability i= ndicators are only defined for SIP. It's a pure SIP mechanism. Regards, Christer From aallen@blackberry.com Tue Oct 29 11:26:56 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D9E11E827B for ; Tue, 29 Oct 2013 11:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2FobQS1z0os for ; Tue, 29 Oct 2013 11:26:51 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9A35111E825D for ; Tue, 29 Oct 2013 11:26:41 -0700 (PDT) Received: from xct102ads.rim.net ([10.67.111.43]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 29 Oct 2013 14:26:29 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.03.0123.003; Tue, 29 Oct 2013 13:26:28 -0500 From: Andrew Allen To: Paul Kyzivat , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUo+ZAiuycmUumaJncVjjxK5oKi8CQgAEa1ICAABo8MIAAWZQAgAAMwoCAAAuwgP//t/4QgABdTID//7vTMA== Date: Tue, 29 Oct 2013 18:26:27 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> , <526FC944.6090903@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4FAAAA@ESESSMB209.ericsson.se> <526FDDC5.6050201@alum.mit.edu> <526FEFA1.2070409@alum.mit.edu> In-Reply-To: <526FEFA1.2070409@alum.mit.edu> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:26:56 -0000 Paul My responses below Andrew -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] = Sent: Tuesday, October 29, 2013 1:26 PM To: Andrew Allen; Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators On 10/29/13 12:57 PM, Andrew Allen wrote: > > Do we agree that if a UA indicates it supports a SIP Method or a SIP exte= nsion or a SIP event package then that UA supports that SIP Method or that = SIP extension or that SIP event package? Are you are asking this in the context of 3840? [AA] I was really asking in the abstract This seems appropriate. But "supports" is a bit slippery. I think we should be able to assume that support was there at the time the = indication was made. But it won't necessarily remain true forever. = And there is no specification of a minimum time that it must remain valid. Also, "support" also can be nuanced in other ways. For instance isFocus may= be true for certain dialogs and not others. So the knowledge imparted by these is "fuzzy". [AA] I think there is a difference between supports the capability and I am= willing to use the capability. Generally support by a platform for a capab= ility IMHO doesn't change that often (I suppose some devices may have plug = in devices such as cameras and headsets that may modify some capabilities).= Willingness to use a capability is something else. > If that same UA also indicates a URI that it can be reached at then that = UA that can be reached at the advertised URI also supports that SIP Method = or that SIP extension or that SIP event package - agree? In the context of 3840, yes. (Given the caveats above.) > So to me the issue to clarify in the global tree FCI that advertises the = URI is whether the URI is hosted by the same UA that also indicates the SIP= capabilities in the SIP tree FCIs. > > Does that make sense? I guess this would be an alternative approach to the one Christer suggested. IIUC, you are saying that the definition of g.xxx.foo might say: - the server posting this FC is a foo server - the server posting this FC is reachable out of dialog at the supplied URI And then the FCI sip.x tag descriptions would say that they describe capabi= lities of the server posting the FC entry. [AA] This seems a little weird, but it might fly. I'd like to hear what other pe= ople think. [AA] One man's weirdness is another mans logic! Thanks, Paul > Andrew > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, October 29, 2013 12:10 PM > To: Christer Holmberg; Andrew Allen; sipcore@ietf.org > Subject: Re: [sipcore] New sipcore draft submission = > draft-allen-sipcore-sip-tree-cap-indicators > > Christer, > > What you say below seems plausible as a way forward. > > It does present a potential problem: > > Suppose you do that. And then another tag g.xxx.foo is defined with a URI= that identifies a foo server and a rule that says the presence or absence = of +sip.audio and +sip.video indicates whether the foo server at the URI su= pports audio and video. > > Then another tag g.xxx.bar is defined with a URI that identifies a bar = > server and a rule that says the presence or absence of +sip.audio and > +sip.video indicates whether the foo server at the URI supports audio > and video. > > Then something inserts a Feature-Caps entry. It wants to indicate a = > foo server that supports audio, and a bar server that supports video. = > It can't do that in a single entry. It could emit two entries as = > Andrew suggested. Is that valid? > > I think it will be necessary to spell out the rules for this sort of = > usage. And this won't necessarily be just for these tags in the sip = > tree. It could apply to other tags as well. If feels more like an = > extension (or maybe just a clarification) of 6809. > > Thanks, > Paul > > On 10/29/13 11:27 AM, Christer Holmberg wrote: >> Hi, >> >>> I would appreciate if the two of you would go off and come up with a = >>> proposal that you both agree is consistent with the language and = >>> intent of RFC 6809. >>> >>> What Christer is suggesting *might* work, though I reserve judgement = >>> until I see that actual language that you settle on. If you go that = >>> way, then I want to see an explanation of how the sip tree tags are spe= cified. >> I think we would have to say that the sip.x FCIs as such don't = >> provide much information. Instead, they can be used together with = >> OTHER FCIs, to provide additional information about those OTHER FCIs. = >> But, the FCI specifcation of such OTHER FCI MUST describe which sip.x = >> FCIs are used to provide additional information, and how. >> Regards, >> Chrsiter >> >> On 10/29/13 10:25 AM, Andrew Allen wrote: >>> Christer >>> >>> My responses inline >>> >>> Andrew >>> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Tuesday, October 29, 2013 3:48 AM >>> To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org >>> Subject: RE: [sipcore] New sipcore draft submission = >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> Hi, >>> >>>> In actual usage many feature capability indicators (FCIs) are being = >>>> used to communicate URIs. The ones that communicate URIs listed = >>>> below are just from one 3GPP 3GPP specification (and there are = >>>> several other specifications that define feature capability = >>>> indicators) and many of these FCIs were defined by the authors of = >>>> RFC 6809. So I think it has been found to be necessary to = >>>> communicate URIs in FCIs. Usually these URIs are used as the = >>>> Request-URI of a SIP >> request and the URI is hosted by the server that included the FCI. >>>> >>>> If a UA indicates a URI hosted by it and a UA also indicates = >>>> certain capabilities such as he supported SIP methods and SIP = >>>> extensions I think you can infer that the UA supports those methods = >>>> and extensions and the UA can be contacted at the URI. When = >>>> contacting the UA at the indicated URI it seems to me to be a = >>>> reasonable assumption to make that the methods and extensions also = >>>> indicated are >> going to be supported. >>>> >>>> If the physical entity inserting the FCIs has different URIs that = >>>> represent logically different UAs (with different SIP methods and exte= nsions supported) then the different logical UAs and their associated capab= ilities should be indicated in different Feature-Caps header fields. >>> >>> Again, I don't think one should make such "default assumption". >>> >>> Instead, the g.xxx.yyy FCI specification needs to explicitly say that, = when used in conjunction with the sip.methods FCI, the sip.methods FCI indi= cates which SIP methods can be used when using the URI provided by the g.xx= x.yyy FCI. >>> >>> [AA] I am OK to go the approach that we state whether the scope of the = FCI (and the URI value of the FCI) is such that other FCIs in the SIP tree = include in the same header field apply to that URI or not. >>> >>> (Of course, the g.xxx.yyy FCI specification itself can also define whic= h SIP methods can be used, if the allowed methods are always the same, in w= hich case there is no need for sip.methods). >>> >>> [AA] I am not happy with that approach - I think that is "hidden magic"= that some feature outside of SIP is defining what SIP features are suppor= ted. >>> >>> Regards, >>> >>> Christer >>> -------------------------------------------------------------------- >>> - This transmission (including any attachments) may contain = >>> confidential information, privileged material (including material = >>> protected by the solicitor-client or other applicable privileges), = >>> or constitute non-public information. Any use of this information = >>> by anyone other than the intended recipient is prohibited. If you = >>> have >> received this transmission in error, please immediately reply to the = >> sender and delete this information from your system. Use, = >> dissemination, distribution, or reproduction of this transmission by = >> unintended recipients is not authorized and may be unlawful. >>> >>> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From aallen@blackberry.com Tue Oct 29 11:29:10 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8166711E8251 for ; Tue, 29 Oct 2013 11:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCAe0DaEVxv3 for ; Tue, 29 Oct 2013 11:29:05 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCD811E824D for ; Tue, 29 Oct 2013 11:28:48 -0700 (PDT) Received: from xct103ads.rim.net ([10.67.111.44]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 29 Oct 2013 14:28:47 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.03.0123.003; Tue, 29 Oct 2013 13:28:46 -0500 From: Andrew Allen To: Christer Holmberg , "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUo+ZAiuycmUumaJncVjjxK5oKi8CQgAEa1ICAABo8MIAAWZQAgAAMwoCAAAuwgP//t/4QgABdTICAAApJAP//r/VDgABVfgD//62CYA== Date: Tue, 29 Oct 2013 18:28:46 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4FAD82@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4FADFF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4FADFF@ESESSMB209.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:29:10 -0000 My proposal is that I modify my draft to define that the sip tree FCIs are = scoped to the entity that inserts them. Then if a global tree FCI is defined that has a URI that is hosted on the e= ntity that inserts it that this is defined in the registration of the globa= l tree FCI. -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] = Sent: Tuesday, October 29, 2013 2:22 PM To: Andrew Allen; pkyzivat@alum.mit.edu; sipcore@ietf.org Subject: VS: VS: [sipcore] New sipcore draft submission draft-allen-sipcore= -sip-tree-cap-indicators Hi, >However if the FCI defines that the URI is hosted by the entity that inser= ted it and the sip tree FCIs are also defined as being scoped to the entity= that inserted them then they would be associated. Absolutely. = But, again, the FCI specification needs to explicitly define that :) Regards, Christer ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, October 29, 2013 01:02 PM Central Standard Time To: Paul Kyzivat ; Andrew Allen; sipcore@ietf.org Subject: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators Hi, In a Contact header field, the URI is a header field parameter, and any med= ia feature tag is by definition associated with that URI. In Feature-Caps, we don't have such "header field level" URI. If you define= a URI value for a FCI, that URI is by default only associated with that FC= I. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] L=E4hetetty: 29. lokakuuta 2013 19:26 Vastaanottaja: Andrew Allen; Christer Holmberg; sipcore@ietf.org Aihe: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tr= ee-cap-indicators On 10/29/13 12:57 PM, Andrew Allen wrote: > > Do we agree that if a UA indicates it supports a SIP Method or a SIP exte= nsion or a SIP event package then that UA supports that SIP Method or that = SIP extension or that SIP event package? Are you are asking this in the context of 3840? This seems appropriate. But "supports" is a bit slippery. I think we should be able to assume that support was there at the time the = indication was made. But it won't necessarily remain true forever. = And there is no specification of a minimum time that it must remain valid. Also, "support" also can be nuanced in other ways. For instance isFocus may= be true for certain dialogs and not others. So the knowledge imparted by these is "fuzzy". > If that same UA also indicates a URI that it can be reached at then that = UA that can be reached at the advertised URI also supports that SIP Method = or that SIP extension or that SIP event package - agree? In the context of 3840, yes. (Given the caveats above.) > So to me the issue to clarify in the global tree FCI that advertises the = URI is whether the URI is hosted by the same UA that also indicates the SIP= capabilities in the SIP tree FCIs. > > Does that make sense? I guess this would be an alternative approach to the one Christer suggested. IIUC, you are saying that the definition of g.xxx.foo might say: - the server posting this FC is a foo server - the server posting this FC is reachable out of dialog at the supplied URI And then the FCI sip.x tag descriptions would say that they describe capabi= lities of the server posting the FC entry. This seems a little weird, but it might fly. I'd like to hear what other pe= ople think. Thanks, Paul > Andrew > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Tuesday, October 29, 2013 12:10 PM > To: Christer Holmberg; Andrew Allen; sipcore@ietf.org > Subject: Re: [sipcore] New sipcore draft submission = > draft-allen-sipcore-sip-tree-cap-indicators > > Christer, > > What you say below seems plausible as a way forward. > > It does present a potential problem: > > Suppose you do that. And then another tag g.xxx.foo is defined with a URI= that identifies a foo server and a rule that says the presence or absence = of +sip.audio and +sip.video indicates whether the foo server at the URI su= pports audio and video. > > Then another tag g.xxx.bar is defined with a URI that identifies a bar = > server and a rule that says the presence or absence of +sip.audio and > +sip.video indicates whether the foo server at the URI supports audio > and video. > > Then something inserts a Feature-Caps entry. It wants to indicate a = > foo server that supports audio, and a bar server that supports video. > It can't do that in a single entry. It could emit two entries as = > Andrew suggested. Is that valid? > > I think it will be necessary to spell out the rules for this sort of = > usage. And this won't necessarily be just for these tags in the sip = > tree. It could apply to other tags as well. If feels more like an = > extension (or maybe just a clarification) of 6809. > > Thanks, > Paul > > On 10/29/13 11:27 AM, Christer Holmberg wrote: >> Hi, >> >>> I would appreciate if the two of you would go off and come up with a = >>> proposal that you both agree is consistent with the language and = >>> intent of RFC 6809. >>> >>> What Christer is suggesting *might* work, though I reserve judgement = >>> until I see that actual language that you settle on. If you go that = >>> way, then I want to see an explanation of how the sip tree tags are spe= cified. >> I think we would have to say that the sip.x FCIs as such don't = >> provide much information. Instead, they can be used together with = >> OTHER FCIs, to provide additional information about those OTHER FCIs. >> But, the FCI specifcation of such OTHER FCI MUST describe which sip.x = >> FCIs are used to provide additional information, and how. >> Regards, >> Chrsiter >> >> On 10/29/13 10:25 AM, Andrew Allen wrote: >>> Christer >>> >>> My responses inline >>> >>> Andrew >>> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Tuesday, October 29, 2013 3:48 AM >>> To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org >>> Subject: RE: [sipcore] New sipcore draft submission = >>> draft-allen-sipcore-sip-tree-cap-indicators >>> >>> Hi, >>> >>>> In actual usage many feature capability indicators (FCIs) are being = >>>> used to communicate URIs. The ones that communicate URIs listed = >>>> below are just from one 3GPP 3GPP specification (and there are = >>>> several other specifications that define feature capability >>>> indicators) and many of these FCIs were defined by the authors of = >>>> RFC 6809. So I think it has been found to be necessary to = >>>> communicate URIs in FCIs. Usually these URIs are used as the = >>>> Request-URI of a SIP >> request and the URI is hosted by the server that included the FCI. >>>> >>>> If a UA indicates a URI hosted by it and a UA also indicates = >>>> certain capabilities such as he supported SIP methods and SIP = >>>> extensions I think you can infer that the UA supports those methods = >>>> and extensions and the UA can be contacted at the URI. When = >>>> contacting the UA at the indicated URI it seems to me to be a = >>>> reasonable assumption to make that the methods and extensions also = >>>> indicated are >> going to be supported. >>>> >>>> If the physical entity inserting the FCIs has different URIs that = >>>> represent logically different UAs (with different SIP methods and exte= nsions supported) then the different logical UAs and their associated capab= ilities should be indicated in different Feature-Caps header fields. >>> >>> Again, I don't think one should make such "default assumption". >>> >>> Instead, the g.xxx.yyy FCI specification needs to explicitly say that, = when used in conjunction with the sip.methods FCI, the sip.methods FCI indi= cates which SIP methods can be used when using the URI provided by the g.xx= x.yyy FCI. >>> >>> [AA] I am OK to go the approach that we state whether the scope of the = FCI (and the URI value of the FCI) is such that other FCIs in the SIP tree = include in the same header field apply to that URI or not. >>> >>> (Of course, the g.xxx.yyy FCI specification itself can also define whic= h SIP methods can be used, if the allowed methods are always the same, in w= hich case there is no need for sip.methods). >>> >>> [AA] I am not happy with that approach - I think that is "hidden magic"= that some feature outside of SIP is defining what SIP features are suppor= ted. >>> >>> Regards, >>> >>> Christer >>> -------------------------------------------------------------------- >>> - This transmission (including any attachments) may contain = >>> confidential information, privileged material (including material = >>> protected by the solicitor-client or other applicable privileges), = >>> or constitute non-public information. Any use of this information by = >>> anyone other than the intended recipient is prohibited. If you have >> received this transmission in error, please immediately reply to the = >> sender and delete this information from your system. Use, = >> dissemination, distribution, or reproduction of this transmission by = >> unintended recipients is not authorized and may be unlawful. >>> >>> >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From aallen@blackberry.com Tue Oct 29 11:33:16 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4AB21F9F3A for ; Tue, 29 Oct 2013 11:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWmLGWbtIAdW for ; Tue, 29 Oct 2013 11:33:10 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 8690D11E818E for ; Tue, 29 Oct 2013 11:33:09 -0700 (PDT) Received: from xct105ads.rim.net ([10.67.111.46]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 29 Oct 2013 14:33:01 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.03.0123.003; Tue, 29 Oct 2013 13:33:01 -0500 From: Andrew Allen To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUo+ZAiuycmUumaJncVjjxK5oKi8CQgAEa1ICAABo8MIAAl9kA//+uSEA= Date: Tue, 29 Oct 2013 18:33:00 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4FAE19@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4FAE19@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.252] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:33:16 -0000 My view is being explicit is much better -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] = Sent: Tuesday, October 29, 2013 2:25 PM To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org Subject: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators > (Of course, the g.xxx.yyy FCI specification itself can also define which = SIP methods can be used, if the allowed methods are always the same, in whi= ch case there is no need for sip.methods). = > > [AA] I am not happy with that approach - I think that is "hidden magic" = that some feature outside of SIP is defining what SIP features are supporte= d. I am not sure what you understand. If a FCI specification says that the URI= value of the +g.xxx.yyy FCI can only be used for SIP method X, I don't see= that as hidden magic. Keep in mind that, unlike media feature tags, usage of feature-capability i= ndicators are only defined for SIP. It's a pure SIP mechanism. Regards, Christer --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Tue Oct 29 11:37:34 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD66611E814F for ; Tue, 29 Oct 2013 11:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.553 X-Spam-Level: X-Spam-Status: No, score=-5.553 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd1E7AzrVO0w for ; Tue, 29 Oct 2013 11:37:00 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACB211E824C for ; Tue, 29 Oct 2013 11:36:54 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-7b-52700041f292 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EC.D9.03802.14000725; Tue, 29 Oct 2013 19:36:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 19:36:49 +0100 From: Christer Holmberg To: Andrew Allen , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators Thread-Index: AQHO0cPUqRBKqAf4v0eC21ZkCIO4WJoKgpMAgADN42CAAGCwgIAAUw+w///yFgCAABEGEA== Date: Tue, 29 Oct 2013 18:36:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4FAE88@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4F6F7D@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B1C4F7024@ESESSMB209.ericsson.se>, <526ABD4B.1030404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F70FF@ESESSMB209.ericsson.se> <526AD459.1080908@alum.mit.edu> <526AD98E.5000907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4F9DD1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4FAE19@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvja4TQ0GQwYu9XBb3521ltFix4QCr xdcfm9gcmD3+vv/A5DGrYS27x5IlP5kCmKO4bFJSczLLUov07RK4Mv4sjy74Jlix8eoVxgbG C3xdjJwcEgImEhtXTGCDsMUkLtxbD2RzcQgJHGKU2Dt9HQuEs4RRYvmE9UAOBwebgIVE9z9t kAYRgXKJxycPgzULCyRKXGjoY4WIJ0n8XXGdDcIOk9j0H6KGRUBV4vW2j2A2r4CvxM3TZ9kh 5jewSZy4OROsmVPAU+L5zc/MIDYj0EXfT61hArGZBcQlPhy8zgxxqYDEkj3noWxRiZeP/7FC 2EoSjUuesELU60gs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUj e25iZk56udEmRmB8HNzyW3UH451zIocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAaHN4tpxeisiUw0/63atkRJcIX1aKq9jfPzvEldG5IFBSMWLdx7vxGWkBYQW39U5s Tdf38b9jG/Hbcde0p7dv3LfLn2yy4uznVdmyBSGbqm2NjrXc/BU9Z3pp48YYw77mJv3+Zzct hS9bO1bfzwrVknqdsz95R258xJ03zhM5pn69qnJy+VcnJZbijERDLeai4kQAC2oyUl0CAAA= Subject: Re: [sipcore] New sipcore draft submission draft-allen-sipcore-sip-tree-cap-indicators X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:37:34 -0000 > My view is being explicit is much better RFC 6809 says that the FCI specification needs to be explicit on how a FCI = is used - either by defining the procedures, or referencing a specification= (e.g. a 3GPP specification) where the procedures are defined. And, those procedures obviously describe, among other things, which SIP met= hods can be used. So, if the same set of methods can always be used, there = is no need to indicate them in the F-C header field. But, if the set of met= hods can vary, then it is of course information that needs to be added. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Tuesday, October 29, 2013 2:25 PM To: Andrew Allen; Paul Kyzivat; sipcore@ietf.org Subject: VS: [sipcore] New sipcore draft submission draft-allen-sipcore-sip= -tree-cap-indicators > (Of course, the g.xxx.yyy FCI specification itself can also define which = SIP methods can be used, if the allowed methods are always the same, in whi= ch case there is no need for sip.methods).=20 > > [AA] I am not happy with that approach - I think that is "hidden magic" = that some feature outside of SIP is defining what SIP features are supporte= d. I am not sure what you understand. If a FCI specification says that the URI= value of the +g.xxx.yyy FCI can only be used for SIP method X, I don't see= that as hidden magic. Keep in mind that, unlike media feature tags, usage of feature-capability i= ndicators are only defined for SIP. It's a pure SIP mechanism. Regards, Christer --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Tue Oct 29 11:54:26 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FBA11E828C for ; Tue, 29 Oct 2013 11:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.564 X-Spam-Level: X-Spam-Status: No, score=-5.564 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6TA71lBtH1K for ; Tue, 29 Oct 2013 11:54:19 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEF011E8286 for ; Tue, 29 Oct 2013 11:54:16 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-85-52700457de10 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4F.51.16099.75400725; Tue, 29 Oct 2013 19:54:15 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 19:54:15 +0100 From: Christer Holmberg To: Andrew Allen , "sipcore@ietf.org" Thread-Topic: Questions regarding use of REFER by RFC 6665 compliant UAs Thread-Index: Ac7UwRyQm5QbMo/XTta8UIVCzdMI+QAFntag Date: Tue, 29 Oct 2013 18:54:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4FAF01@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4FAF01ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvjW44S0GQwdwLWhb3521ltPj6YxOb A5PHrIa17B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo43/+YraBzJ2NF41PjBsZjCxm7GDk4JARM JCZtiOpi5AQyxSQu3FvPBmILCRxilNhyHKiEC8hewiix4mYjO0g9m4CFRPc/bZAaEYFAibfN 79lBbGEBd4n/i6+zQMQ9JH583scEYRtJnOt7zApiswioSqxdfB5sPq+Ar8Sl5meMELs8JK6t uwJWwyngKdH3+BvYHEage76fWgM2h1lAXOLDwevMEHcKSCzZcx7KFpV4+fgfK4StJNG45Akr RH2+xOquX4wQuwQlTs58wjKBUWQWklGzkJTNQlIGEdeTuDF1ChuErS2xbOFrqHpdiRn/DrEg iy9gZF/FyJ6bmJmTXm64iREYOQe3/NbdwXjqnMghRmkOFiVx3g9vnYOEBNITS1KzU1MLUovi i0pzUosPMTJxcEo1MHKUSN1j+yO4pnpC0jmO2LQIm4aW2LBSm+5g/vXSVxYs+RDyeWtGaZ/s XIN770r+vuAyX5tVrcXs8e+1XDx3/+eHdTFG4bF7GBdvkciav05AbVL952vSp/N2CH96KPWL 9Wpoa8+c/htvJ5YKZX9JLgwUuPvi3FpNT627HwuXvyusiJnJe+t/ixJLcUaioRZzUXEiAGb3 5AtqAgAA Subject: Re: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:54:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4FAF01ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In my view it is ok to send a REFER within an INVITE dialog, if the sender = knows that the receiver will not create a subscription. HOW the sender knows that (whether usage of Require:norefersub would guaran= tee it, or whether the knowledge is based on some other information) is out= side the scope, I think. Having said that, I do agree that the text in RFC 5057 seems misleading, as= it seems to generally indicate that a subscription will never be created w= hen a REFER utilizes norefersub. Regards, Christer L=E4hett=E4j=E4: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org]= Puolesta Andrew Allen L=E4hetetty: 29. lokakuuta 2013 19:31 Vastaanottaja: sipcore@ietf.org Aihe: [sipcore] Questions regarding use of REFER by RFC 6665 compliant UAs Recently there has been some offline discussion regarding the impact of RFC= 6665 on the use of REFER. Particularly on whether an RFC 6665 compliant UA= can send a REFER using a dialog created by another SIP method other than f= or interoperability with UAs that don't support GRUU and RFC 6665. RFC 6665 deprecates dialog reuse for subscriptions. REFER can create also c= reate an implicit subscription. RFC 6665 states: .... the dialog reuse technique described in RFC 3265 is now deprec= ated. This dialog-sharing technique has also historically been used as a means for targeting an event package at a dialog. This usage can be seen, for example, in certain applications of the REFER method [RFC3515]. With the removal of dialog reuse, an alternate (and more explicit) means of targeting dialogs needs to be used for this type of correlation. The appropriate means of such targeting is left up to the actual event packages. Candidates include the "Target-Dialog" header field [RFC4538], the "Join" header field [RFC3911], and the "Replaces" header field [RFC3891], depending on the semantics desired. And Further note that the prohibition on reusing dialogs does not exempt implicit subscriptions created by the REFER method. This means that implementations complying with this specification are required to use the "Target-Dialog" mechanism described in [RFC4538] when the remote target is a GRUU. However RFC 4488 provides a means to request a REFER recipient not to creat= e an implicit subscription through the use of Refer-Sub: false. However the= text of RFC 4488 does not require that the REFER recipient not create an i= mplicit subscription since RFC 4488 states: If the REFER-Recipient supports the extension and is willing to process = the REFER transaction without establishing an implicit subscription, it MUS= T insert the "Refer-Sub" header field set to "false" in the 2xx response to= the REFER-Issuer. The key words here are "and is WILLING to process the REFER transaction wit= hout establishing an implicit subscription" so there is always the possibil= ity that a subscription will be created even if norefersub is supported and= Refer-Sub header field is set to FALSE. However RFC 5057 seems to be in conflict with RFC 4488 in this regard stati= ng: Dialogs with multiple usages arise when a usage-creating action occurs inside an existing dialog. Such actions include accepting a REFER or SUBSCRIBE issued inside a dialog established with an INVITE request. Multiple REFERs within a dialog create multiple subscriptions, each of which is a new dialog usage sharing common dialog state. (Note that any REFER issued utilizing the subscription-suppression mechanism specified in [2] creates no new usage.) Similarly, an endpoint in a dialog established with an INVITE might subscribe to its peer's Key Press Markup Language (KPML) [3] and later issue a REFER, resulting in three dialog usages sharing common dialog state. So the first question is if an RFC 6665 compliant UA indicated either Requi= re: norefersub or knows that the REFER recipient supports norefersub and al= so indicates Refer-Sub: False in the REFER request can that REFER request = be sent on a dialog created by another Method (in the safe knowledge that n= o subscription will be created)? If the answer to the first question is no - an implicit subscription could = still be created. Can some other knowledge that the REFER recipient will not create an implic= it subscription - such as the definition in another specification outside o= f IETF of a feature that mandates that no subscription be created by the RE= FER recipient and the indication of the support of such a feature by the RE= FER recipient in a global tree media feature tag has been received by the R= EFER sender. Does this allow an RFC 6665 UA to send the REFER on a dialog c= reated by another Method? I have discussed the issue with Adam Roach offline and his view and mine is= that RFC 6665 UAs do not send REFER requests sent on a dialog created by a= nother Method except for interoperability with UAs that don't support GRUU = and RFC 6665. What is the view of the rest of the community? Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_7594FB04B1934943A5C02806D1A2204B1C4FAF01ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

In my v= iew it is ok to send a REFER within an INVITE dialog, if the sender knows that the receiver will not create a subscription.

&n= bsp;

HOW the= sender knows that (whether usage of Require:norefersub would guarantee it,= or whether the knowledge is based on some other information) is outside th= e scope, I think.

&n= bsp;

Having = said that, I do agree that the text in RFC 5057 seems misleading, as it see= ms to generally indicate that a subscription will never be created when a R= EFER utilizes norefersub.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

&n= bsp;

&n= bsp;

L=E4hett=E4j=E4: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Puolesta Andrew Allen
L=E4hetetty: 29. lokakuuta 2013 19:31
Vastaanottaja: sipcore@ietf.org
Aihe: [sipcore] Questions regarding use of REFER by RFC 6665 complia= nt UAs

 

 

Recently there has been some of= fline discussion regarding the impact of RFC 6665 on the use of REFER. Part= icularly on whether an RFC 6665 compliant UA can send a REFER using a dialo= g created by another SIP method other than for interoperability with UAs that don’t support GRUU and RFC 6= 665.

 

RFC 6665 deprecates dialog reus= e for subscriptions. REFER can create also create an implicit subscription.=

 

RFC 6665 states:

 

&= nbsp;       …. the dialog reuse techniqu= e described in RFC 3265 is now deprecated.

 

   This dialog-shari= ng technique has also historically been used as a

   means for targeti= ng an event package at a dialog.  This usage can be<= /p>

   seen, for example= , in certain applications of the REFER method

   [RFC3515].  = With the removal of dialog reuse, an alternate (and more<= /p>

   explicit) means o= f targeting dialogs needs to be used for this type

   of correlation.&n= bsp; The appropriate means of such targeting is left up

   to the actual eve= nt packages.  Candidates include the "Target-Dialog"

   header field [RFC= 4538], the "Join" header field [RFC3911], and the

   "Replaces&qu= ot; header field [RFC3891], depending on the semantics

   desired.

 

And

 

     = Further note that the prohibition on reusing dialogs does not

     = exempt implicit subscriptions created by the REFER method.  This=

     = means that implementations complying with this specification are

     = required to use the "Target-Dialog" mechanism described in<= /o:p>

     = [RFC4538] when the remote target is a GRUU.

 

 

However RFC 4488 provides a mea= ns to request a REFER recipient not to create an implicit subscription thro= ugh the use of Refer-Sub: false. However the text of RFC 4488 does not requ= ire that the REFER recipient not create an implicit subscription since RFC 4488 states:

 

   If the REFER-Reci= pient supports the extension and is willing to process the REFER transaction without establishing an = implicit subscription, it MUST insert the "Refer-Sub" header = field set to "false" in the 2xx response to the REFER-Issuer.&nbs= p;

&n= bsp;

The key= words here are “and is WILLING to process the REFER transaction with= out establishing an implicit subscription” so there is always the pos= sibility that a subscription will be created even if norefersub is supported and Refer-Sub header field is set to FALSE.

 

However RFC 5057 seems to be in= conflict with RFC 4488 in this regard stating:

 

 <= /o:p>

  = Dialogs with multiple usages arise when a usage-creating action=

  = occurs inside an existing dialog.  Such actions include accepting a

  = REFER or SUBSCRIBE issued inside a dialog established with an INVITE<= /o:p>

  = request.  Multiple REFERs within a dialog create multiple<= /span>

  = subscriptions, each of which is a new dialog usage sharing common

  = dialog state.  (Note that any REFER issued utilizing the

 &nb= sp; subscription-suppression mechanism specified in [2] creates no new=

 &nb= sp; usage.)  Simila= rly, an endpoint in a dialog established with an

  = INVITE might subscribe to its peer's Key Press Markup Language (KPML)=

  = [3] and later issue a REFER, resulting in three dialog usages sharing=

  = common dialog state.

 <= /o:p>

 

So the first question is if an = RFC 6665 compliant UA indicated either Require: norefersub or knows that th= e REFER recipient supports norefersub and also indicates Refer-Sub: False i= n the REFER request  can that REFER request be sent on a dialog created by another Method (in the safe knowled= ge that no subscription will be created)?

 

If the answer to the first ques= tion is no – an implicit subscription could still be created.

 

Can some other knowledge that t= he REFER recipient will not create an implicit subscription - such as the d= efinition in another specification outside of IETF of a feature that mandat= es that no subscription be created by the REFER recipient and the indication of the support of such a feature by= the REFER recipient in a global tree media feature tag has been received b= y the REFER sender. Does this allow an RFC 6665 UA to send the REFER on a d= ialog created by another Method?

 

I have discussed the issue with= Adam Roach offline and his view and mine is that RFC 6665 UAs do not send = REFER requests sent on a dialog created by another Method except for intero= perability with UAs that don’t support GRUU and RFC 6665.

 

What is the view of the rest of= the community?

 

Andrew

---------------------= ------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.=

--_000_7594FB04B1934943A5C02806D1A2204B1C4FAF01ESESSMB209erics_--