From internet-drafts@ietf.org Fri Jun 8 11:26:01 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD09A21F87D5; Fri, 8 Jun 2012 11:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, 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 Q6SZLiD5Y8tj; Fri, 8 Jun 2012 11:26:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF3021F87CA; Fri, 8 Jun 2012 11:26:01 -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.02 Message-ID: <20120608182601.16798.55547.idtracker@ietfa.amsl.com> Date: Fri, 08 Jun 2012 11:26:01 -0700 Cc: bliss@ietf.org Subject: [BLISS] I-D Action: draft-ietf-bliss-shared-appearances-11.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 18:26:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Basic Level of Interoperability for S= IP Services Working Group of the IETF. Title : Shared Appearances of a Session Initiation Protocol (SIP= ) Address of Record (AOR) Author(s) : Alan Johnston Mohsen Soroushnejad Venkatesh Venkataramanan Filename : draft-ietf-bliss-shared-appearances-11.txt Pages : 70 Date : 2012-06-08 This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements and defines extensions to implement this feature. This specification updates RFC3261 and RFC4235. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-11.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-11.t= xt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bliss-shared-appearances/ From alan.b.johnston@gmail.com Fri Jun 8 12:35:35 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9ED11E8120 for ; Fri, 8 Jun 2012 12:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.765 X-Spam-Level: X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 f+pI2f65mNOC for ; Fri, 8 Jun 2012 12:35:34 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7646811E8094 for ; Fri, 8 Jun 2012 12:35:34 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so3582201obb.31 for ; Fri, 08 Jun 2012 12:35:34 -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 :content-type; bh=PAMrifhf5jlmK2mKr1VoOXrQeRK+ADwDcfYX5C7WR00=; b=JQnaQmI75Lej7tKSjEzbQbnu8mBlVSvjuIKQ1kHxOQQpDmvji29/pwm6yBduiKNnVO zStgysNDCvAgliF92LO/8EnH2FAxkArNa09LLwvGwqLJPUmJCr6G+p6eo0lI1PGQn4kU wF/ySYzftr8SJp0FlaKzIqSl0fgAxF5riK9Dp0w73UxFpedzk6qDHxSBXmhzI2IqjbBf O+/CoWCOO4CQN3CczG4lhM9bwDhYs1Ac8INEuAcBYTKpMigiJZWZ6lLmVJfdj9/f0wzf viNGz6fozXfVjuM93KP071jgAgwWffRkKymdiuuMPPyEpopXOv4jvcV5+qUp/iCxJPvE LI7Q== MIME-Version: 1.0 Received: by 10.182.12.74 with SMTP id w10mr8258910obb.54.1339184133977; Fri, 08 Jun 2012 12:35:33 -0700 (PDT) Received: by 10.182.13.136 with HTTP; Fri, 8 Jun 2012 12:35:33 -0700 (PDT) In-Reply-To: <20120608182601.16798.55547.idtracker@ietfa.amsl.com> References: <20120608182601.16798.55547.idtracker@ietfa.amsl.com> Date: Fri, 8 Jun 2012 14:35:33 -0500 Message-ID: From: Alan Johnston To: bliss@ietf.org Content-Type: multipart/alternative; boundary=f46d044468db9834b704c1fb1a75 Subject: Re: [BLISS] I-D Action: draft-ietf-bliss-shared-appearances-11.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 19:35:35 -0000 --f46d044468db9834b704c1fb1a75 Content-Type: text/plain; charset=ISO-8859-1 All, This document has a number of updates based on AD review and other reviews which are summarized below. The changes are based on changes since the -09 version from December. Comments are most welcome! Thanks to everyone for their reviews and feedback. - Alan - - Changed conflicting text on element. True means the call/dialog cannot be replaced or joined. The default is False if not specified. - Added missing normative text on the usage of the 'shared' event parameter. - Clarified that UAs do not insert appearance parameter into Alert-Info - Clarified what happens if a UA in group sends an INVITE to the group AOR. This uses two appearance numbers. - Removed text about proxies removing Alert-Info header fields - Clarified that subscriptions and publications must be authorized. - Made security considerations text consistent with that in Replaces and Join RFCs. - Added IANA section on registration of 'appearance' parameter to Alert-Info header field - Fixed error in URN registration On Fri, Jun 8, 2012 at 1:26 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Basic Level of > Interoperability for SIP Services Working Group of the IETF. > > Title : Shared Appearances of a Session Initiation > Protocol (SIP) Address of Record (AOR) > Author(s) : Alan Johnston > Mohsen Soroushnejad > Venkatesh Venkataramanan > Filename : draft-ietf-bliss-shared-appearances-11.txt > Pages : 70 > Date : 2012-06-08 > > This document describes the requirements and implementation of a > group telephony feature commonly known as Bridged Line Appearance > (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line > Appearance (SCA). When implemented using the Session Initiation > Protocol (SIP), it is referred to as shared appearances of an Address > of Record (AOR) since SIP does not have the concept of lines. This > feature is commonly offered in IP Centrex services and IP-PBX > offerings and is likely to be implemented on SIP IP telephones and > SIP feature servers used in a business environment. This feature > allows several user agents (UAs) to share a common AOR, learn about > calls placed and received by other UAs in the group, and pick up or > join calls within the group. This document discusses use cases, > lists requirements and defines extensions to implement this feature. > This specification updates RFC3261 and RFC4235. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-11.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-11.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-bliss-shared-appearances/ > > _______________________________________________ > 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 > --f46d044468db9834b704c1fb1a75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

This document has a number of updates based on AD r= eview and other reviews which are summarized below.

The = changes are based on changes since the -09 version from December.

Comments are most welcome! =A0Thanks to everyone for their r= eviews and feedback.

- Alan -

=
- Changed conflicting text on <exclusive> element. =A0True means= the call/dialog cannot be replaced or joined. =A0The default is False if n= ot specified.

- Added missing normative text on the usage of the '= ;shared' event parameter.

- Clarified that UAs= do not insert appearance parameter into Alert-Info

- Clarified what happens if a UA in group sends an INVITE to the group= AOR. =A0This uses two appearance numbers.

- Remov= ed text about proxies removing Alert-Info header fields

- Clarified that subscriptions and publications must be authorized.

- Made security considerations text consistent with = that in Replaces and Join RFCs.

- Added IANA secti= on on registration of 'appearance' parameter to Alert-Info header f= ield

- Fixed error in URN registration

<= div>

On Fri, Jun 8, 2012 at 1:26 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Basic Level of Interoperability for S= IP Services Working Group of the IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Shared Appearances of a Session= Initiation Protocol (SIP) Address of Record (AOR)
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Alan Johnston
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mohsen Soroushnejad
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Venkatesh Venkataramana= n
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-bliss-shared-appearanc= es-11.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 70
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-06-08

=A0 This document describes the requirements and implementation of a
=A0 group telephony feature commonly known as Bridged Line Appearance
=A0 (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
=A0 Appearance (SCA). =A0When implemented using the Session Initiation
=A0 Protocol (SIP), it is referred to as shared appearances of an Address<= br> =A0 of Record (AOR) since SIP does not have the concept of lines. =A0This<= br> =A0 feature is commonly offered in IP Centrex services and IP-PBX
=A0 offerings and is likely to be implemented on SIP IP telephones and
=A0 SIP feature servers used in a business environment. =A0This feature =A0 allows several user agents (UAs) to share a common AOR, learn about =A0 calls placed and received by other UAs in the group, and pick up or =A0 join calls within the group. =A0This document discusses use cases,
=A0 lists requirements and defines extensions to implement this feature. =A0 This specification updates RFC3261 and RFC4235.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft= -ietf-bliss-shared-appearances-11.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-i= etf-bliss-shared-appearances-11.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bliss-= shared-appearances/

_______________________________________________
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

--f46d044468db9834b704c1fb1a75-- From shida@ntt-at.com Fri Jun 8 23:06:28 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869D921F89AF for ; Fri, 8 Jun 2012 23:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.921 X-Spam-Level: X-Spam-Status: No, score=-101.921 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, 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 3GLwYyteYGpL for ; Fri, 8 Jun 2012 23:06:27 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id A232321F8946 for ; Fri, 8 Jun 2012 23:06:27 -0700 (PDT) Received: from [211.13.69.210] (port=59396 helo=[192.168.1.12]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SdEoc-0006E6-FA; Sat, 09 Jun 2012 01:06:26 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_B0840723-628B-41D3-BAA3-FC6C0D1197EB" From: Shida Schubert In-Reply-To: Date: Sat, 9 Jun 2012 15:06:23 +0900 Message-Id: <23D851D2-F930-438C-B97E-F0EA5FE33895@ntt-at.com> References: <20120608182601.16798.55547.idtracker@ietfa.amsl.com> To: Alan Johnston X-Mailer: Apple Mail (2.1278) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.12]) [211.13.69.210]:59396 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: bliss@ietf.org Subject: Re: [BLISS] I-D Action: draft-ietf-bliss-shared-appearances-11.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 06:06:28 -0000 --Apple-Mail=_B0840723-628B-41D3-BAA3-FC6C0D1197EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Alan; Thanks for the update, the changes look good. Regards Shida as chair On Jun 9, 2012, at 4:35 AM, Alan Johnston wrote: > All, >=20 > This document has a number of updates based on AD review and other = reviews which are summarized below. >=20 > The changes are based on changes since the -09 version from December. >=20 > Comments are most welcome! Thanks to everyone for their reviews and = feedback. >=20 > - Alan - >=20 > - Changed conflicting text on element. True means the = call/dialog cannot be replaced or joined. The default is False if not = specified. >=20 > - Added missing normative text on the usage of the 'shared' event = parameter. >=20 > - Clarified that UAs do not insert appearance parameter into = Alert-Info >=20 > - Clarified what happens if a UA in group sends an INVITE to the group = AOR. This uses two appearance numbers. >=20 > - Removed text about proxies removing Alert-Info header fields >=20 > - Clarified that subscriptions and publications must be authorized. >=20 > - Made security considerations text consistent with that in Replaces = and Join RFCs. >=20 > - Added IANA section on registration of 'appearance' parameter to = Alert-Info header field >=20 > - Fixed error in URN registration >=20 >=20 >=20 > On Fri, Jun 8, 2012 at 1:26 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Basic Level of = Interoperability for SIP Services Working Group of the IETF. >=20 > Title : Shared Appearances of a Session Initiation = Protocol (SIP) Address of Record (AOR) > Author(s) : Alan Johnston > Mohsen Soroushnejad > Venkatesh Venkataramanan > Filename : draft-ietf-bliss-shared-appearances-11.txt > Pages : 70 > Date : 2012-06-08 >=20 > This document describes the requirements and implementation of a > group telephony feature commonly known as Bridged Line Appearance > (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line > Appearance (SCA). When implemented using the Session Initiation > Protocol (SIP), it is referred to as shared appearances of an = Address > of Record (AOR) since SIP does not have the concept of lines. This > feature is commonly offered in IP Centrex services and IP-PBX > offerings and is likely to be implemented on SIP IP telephones and > SIP feature servers used in a business environment. This feature > allows several user agents (UAs) to share a common AOR, learn about > calls placed and received by other UAs in the group, and pick up or > join calls within the group. This document discusses use cases, > lists requirements and defines extensions to implement this feature. > This specification updates RFC3261 and RFC4235. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-11= .txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-11.= txt >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-bliss-shared-appearances/ >=20 > _______________________________________________ > 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 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss --Apple-Mail=_B0840723-628B-41D3-BAA3-FC6C0D1197EB Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

Alan;

 Thanks for the update, the changes look good.

 Regards
  Shida as chair

On Jun 9, 2012, at 4:35 AM, Alan Johnston wrote:

All,

This document has a number of updates based on AD review and other reviews which are summarized below.

The changes are based on changes since the -09 version from December.

Comments are most welcome!  Thanks to everyone for their reviews and feedback.

- Alan -

- Changed conflicting text on <exclusive> element.  True means the call/dialog cannot be replaced or joined.  The default is False if not specified.

- Added missing normative text on the usage of the 'shared' event parameter.

- Clarified that UAs do not insert appearance parameter into Alert-Info

- Clarified what happens if a UA in group sends an INVITE to the group AOR.  This uses two appearance numbers.

- Removed text about proxies removing Alert-Info header fields

- Clarified that subscriptions and publications must be authorized.

- Made security considerations text consistent with that in Replaces and Join RFCs.

- Added IANA section on registration of 'appearance' parameter to Alert-Info header field

- Fixed error in URN registration



On Fri, Jun 8, 2012 at 1:26 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF.

       Title           : Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)
       Author(s)       : Alan Johnston
                         Mohsen Soroushnejad
                         Venkatesh Venkataramanan
       Filename        : draft-ietf-bliss-shared-appearances-11.txt
       Pages           : 70
       Date            : 2012-06-08

  This document describes the requirements and implementation of a
  group telephony feature commonly known as Bridged Line Appearance
  (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
  Appearance (SCA).  When implemented using the Session Initiation
  Protocol (SIP), it is referred to as shared appearances of an Address
  of Record (AOR) since SIP does not have the concept of lines.  This
  feature is commonly offered in IP Centrex services and IP-PBX
  offerings and is likely to be implemented on SIP IP telephones and
  SIP feature servers used in a business environment.  This feature
  allows several user agents (UAs) to share a common AOR, learn about
  calls placed and received by other UAs in the group, and pick up or
  join calls within the group.  This document discusses use cases,
  lists requirements and defines extensions to implement this feature.
  This specification updates RFC3261 and RFC4235.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-11.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-11.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bliss-shared-appearances/

_______________________________________________
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

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

--Apple-Mail=_B0840723-628B-41D3-BAA3-FC6C0D1197EB-- From iesg-secretary@ietf.org Thu Jun 14 11:35:02 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55F421F8743; Thu, 14 Jun 2012 11:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, 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 Ww8Wbk2RbSO4; Thu, 14 Jun 2012 11:35:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A53621F8738; Thu, 14 Jun 2012 11:35:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120614183502.29856.71890.idtracker@ietfa.amsl.com> Date: Thu, 14 Jun 2012 11:35:02 -0700 Cc: bliss@ietf.org Subject: [BLISS] Last Call: (Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)) to Proposed Standard X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 18:35:03 -0000 The IESG has received a request from the Basic Level of Interoperability for SIP Services WG (bliss) to consider the following document: - 'Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-06-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements and defines extensions to implement this feature. This specification updates RFC3261 and RFC4235. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-bliss-shared-appearances/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-bliss-shared-appearances/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1157/ http://datatracker.ietf.org/ipr/1175/ From david.black@emc.com Thu Jun 28 13:51:44 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC5421F8526; Thu, 28 Jun 2012 13:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, 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 vg1LkAWUb-E4; Thu, 28 Jun 2012 13:51:42 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 47F6A21F8593; Thu, 28 Jun 2012 13:51:41 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5SKpcOB030462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jun 2012 16:51:39 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 28 Jun 2012 16:51:16 -0400 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5SKpEHi013407; Thu, 28 Jun 2012 16:51:14 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Thu, 28 Jun 2012 16:51:14 -0400 From: To: , , , Date: Thu, 28 Jun 2012 16:51:13 -0400 Thread-Topic: Gen-ART review of draft-ietf-bliss-shared-appearances-11 Thread-Index: Ac1Vb8Dn5IHpqMlJQDmiZm9plrtFJQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3A7FD@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Thu, 28 Jun 2012 17:06:48 -0700 Cc: bliss@ietf.org, david.black@emc.com, ietf@ietf.org Subject: [BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-11 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 20:51:45 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-bliss-shared-appearances-11 Reviewer: David L. Black Review Date: June 28, 2012 IETF LC End Date: June 28, 2012 IESG Telechat date: (if known) Summary: This draft is on the right track but has open issues, described in the revi= ew. This draft describes support for shared appearances in support of multi-lin= e and shared-line telephone often found in businesses. All of the open issue= s are minor. The draft is well-written and reasonably clear for the most par= t, although significant SIP expertise is required to completely understand it. Major issues: None. Minor issues: 4.1 - REQ-16: in this case, seizing the line is the same thing as dialing. That seems wrong - I would have thought it was a "prerequisite" as opposed to "the same thing" because seizing the line is immediately followed by a dialing request. 5.3. A user may select an appearance number but then abandon placing a call (go back on hook). In this case, the UA MUST free up the appearance number by removing the event state with a PUBLISH as described in [RFC3903]. What happens when that can't be done due to UA or network failure? 5.4. A 400 response is returned if the chosen appearance number is invalid, Is that always a 400 (Bad Request) or is any 4xx response allowed? If it's always 400, add the words "Bad Request" after "400". If the Appearance Agent policy does not allow this, a 400 response is returned. Same question. In addition, is 403 Forbidden allowed here? If an INVITE is sent by a member of the group to the shared AOR (i.e. they call their own AOR), the Appearance Agent MUST assign two appearance numbers. The first appearance number will be the one selected or assigned to the outgoing INVITE. The second appearance number will be another one assigned by the Appearance Agent for the INVITE as it is forked back to the members of the group. How does that interact with the single appearance UAs in 8.1.1 that won't understand the second appearance number? A warning that such a UA can't pick up its call to its own AOR would suffice, either here or in 8.1.1. 9.1=20 A UA that has no knowledge of appearances must will only have appearance numbers for outgoing calls if assigned by the Appearance Agent. If the non-shared appearance UA does not support Join or Replaces, all dialogs could be marked "exclusive" to indicate that these options are not available. Should that "could be marked" be changed to "SHOULD be marked" ? Also, analogous questions for "could" in 9.2 and "can" in 9.3. All three of these affect interoperability. 12. Security Considerations In general, this section is weak on rationale - the second, third and fourth paragraphs should all explain more about the purpose of and/or rationale for their security requirements (e.g., what does the security mechanism protect against and when/why might that protection be desired and/or required?). NOTIFY or PUBLISH message bodies that provide the dialog state information and the dialog identifiers MAY be encrypted end-to-end using the standard mechanisms. What are "the standard mechanisms"? List them, and provide references, please. Please ensure that the section 6 XML and Section 7 ABNF are syntax-checked with actual tools. Nits/editorial comments: p.10: The next section discusses the operations used to implement parts of the shared appearance feature. "The following list describes the operations ..." would be better. 5.3.1. A UA wanting to place a call but not have an appearance number assigned publishes before sending the INVITE without an 'appearance' element but with the 'shared' event package parameter present. I think I understand what was intended here, but this would be clearer if "publishes" was replaced with language about sending a PUBLISH. It's also not completely clear whether "without" applies to the INVITE or the PUBLISH, so this sentence probably needs to be reworded. 5.4. - Expand B2BUA acronym on first use. idnits 2.12.13 ran clean. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From alan.b.johnston@gmail.com Thu Jun 28 18:05:29 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0575F11E80FA; Thu, 28 Jun 2012 18:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 kKLshi9zm47k; Thu, 28 Jun 2012 18:05:28 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B5D1911E80A2; Thu, 28 Jun 2012 18:05:27 -0700 (PDT) Received: by yenq13 with SMTP id q13so2595199yen.31 for ; Thu, 28 Jun 2012 18:05:27 -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:content-transfer-encoding; bh=UKpmvQQl3KGBpTU+DKE/cWv4M90OECLV/6XPcxRaL1c=; b=E38N3onfj44+nigxSdK83N5XPWeq7LzXqseQFUvQqRV3GkxRBRTJLJYP4iB464muEB in7FIuOHip+PfogC81slJRE9TY6nNmfiiu2du5W57RsET6aSVyzWqn2ZY1bvA7xcy3EV YzzRn4V3AQQ7MzXeea7/kjK4EY0rvRgGB74qZRcFPBk8XC3XbQyTOrMjBqE4xf+dHMIj 9iMrwBqYUwpMRINa/KyXw7SVynnFzGnsMxWdjQzOKu3C9ykjGkaF9+pH8/PHtSVZ7pd8 xOnD4U80B2ownVoT3l/JLkKMJ2Xh0opHhkrxG6jUPDFnDXey5Q0K5PXUb28HH8MUHpbV Ru3Q== MIME-Version: 1.0 Received: by 10.42.130.68 with SMTP id u4mr1429708ics.17.1340931925588; Thu, 28 Jun 2012 18:05:25 -0700 (PDT) Received: by 10.231.228.135 with HTTP; Thu, 28 Jun 2012 18:05:25 -0700 (PDT) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208D3A7FD@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208D3A7FD@MX15A.corp.emc.com> Date: Thu, 28 Jun 2012 20:05:25 -0500 Message-ID: From: Alan Johnston To: david.black@emc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mohsen.soroush@sylantro.com, ietf@ietf.org, gen-art@ietf.org, bliss@ietf.org Subject: Re: [BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-11 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 01:05:29 -0000 David, Thank you for your review of the document. =A0See below for how I propose to resolve the issues you have raised. Let me know if you have any other issues or concerns. - Alan - On Thu, Jun 28, 2012 at 3:51 PM, wrote: > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-bliss-shared-appearances-11 > Reviewer: David L. Black > Review Date: June 28, 2012 > IETF LC End Date: June 28, 2012 > IESG Telechat date: (if known) > > Summary: > > This draft is on the right track but has open issues, described in the re= view. > > This draft describes support for shared appearances in support of multi-l= ine > and shared-line telephone often found in businesses. =A0All of the open i= ssues > are minor. =A0The draft is well-written and reasonably clear for the most= part, > although significant SIP expertise is required to completely understand i= t. > > Major issues: =A0None. > > Minor issues: > > 4.1 - REQ-16: > > =A0 in this case, seizing the line is the same thing as dialing. > > That seems wrong - I would have thought it was a "prerequisite" as > opposed to "the same thing" because seizing the line is immediately > followed by a dialing request. This requirement is about sending one request that causes both actions to occur. =A0In a PSTN ringdown circuit (a very specialized circuit, used for "hotlines"), the two operations are the same thing. =A0Besides this statement, is REQ-16 itself not clear? =A0Perhaps I should just remove this statement if it adds confusion rather than clarity to the requirement. > > > 5.3. > > =A0 A user may select an appearance number but then abandon placing a > =A0 call (go back on hook). =A0In this case, the UA MUST free up the > =A0 appearance number by removing the event state with a PUBLISH as > =A0 described in [RFC3903]. > > What happens when that can't be done due to UA or network failure? A little further down in this section says: "=A0 This publication state is refreshed as described in [RFC3903] during =A0 =A0the early dialog state or the Appearance Agent may reassign the =A0 =A0appearance number." So if the removal publish is lost, it will eventually timeout since it is not refreshed. This is standard PUBLISH behavior described in RFC 3903. > > > 5.4. > > =A0 A 400 response is returned if the chosen appearance number is invalid= , > > Is that always a 400 (Bad Request) or is any 4xx response allowed? =A0If > it's always 400, add the words "Bad Request" after "400". We chose 400 in particular, although any 4xx response would have the same result. "Bad Request" is the reason phrase, and the practice of putting it in () is a convention commonly used in SIP documents. The actual reason phrase can be different, customized ("Invalid Appearance") if desired, or in a different language. So in this case we are specifying the 400 response. > > =A0 If the Appearance Agent policy does not allow this, a 400 response > =A0 is returned. > > Same question. =A0In addition, is 403 Forbidden allowed here? 403 is usually used in SIP to indicate that the request has failed due to an authorization policy, and the request can be retried with different credentials. That doesn't quite fit here. > > =A0 If an INVITE is sent by a member of the group to the shared AOR (i.e. > =A0 they call their own AOR), the Appearance Agent MUST assign two > =A0 appearance numbers. =A0The first appearance number will be the one > =A0 selected or assigned to the outgoing INVITE. =A0The second appearance > =A0 number will be another one assigned by the Appearance Agent for the > =A0 INVITE as it is forked back to the members of the group. > > How does that interact with the single appearance UAs in 8.1.1 that won't > understand the second appearance number? =A0A warning that such a UA can'= t > pick up its call to its own AOR would suffice, either here or in 8.1.1. I will put text in 8.1.1 that makes this point clear. > > 9.1 > > =A0 A UA that has no knowledge of appearances must will only have > =A0 appearance numbers for outgoing calls if assigned by the Appearance > =A0 Agent. =A0If the non-shared appearance UA does not support Join or > =A0 Replaces, all dialogs could be marked "exclusive" to indicate that > =A0 these options are not available. > > Should that "could be marked" be changed to "SHOULD be marked" ? > Also, analogous questions for "could" in 9.2 and "can" in 9.3. > > All three of these affect interoperability. I can change this to SHOULD. Actually, it doesn't affect interoperability, as "exclusive" is just a hint, for user experience and interface purposes and to reduce failed requests. If a Join or Replace is inadvertently sent, the operation will fail, which is the same result as not allowing it, although a worse user experience. > > 12. Security Considerations > > In general, this section is weak on rationale - the second, third and > fourth paragraphs should all explain more about the purpose of and/or > rationale for their security requirements (e.g., what does the security > mechanism protect against and when/why might that protection be desired > and/or required?). Right, the mechanisms are to provide privacy and to prevent hijacking/spoofing. I can add text to make this clear. > > =A0 NOTIFY or PUBLISH message bodies that provide the dialog state > =A0 information and the dialog identifiers MAY be encrypted end-to-end > =A0 using the standard mechanisms. > > What are "the standard mechanisms"? =A0List them, and provide references, > please. That would be S/MIME as described in RFC 3261. I can add this. > > Please ensure that the section 6 XML and Section 7 ABNF are > syntax-checked with actual tools. I will double check them. > > Nits/editorial comments: > > p.10: > > =A0 The next section discusses the operations used to implement parts of > =A0 the shared appearance feature. > > "The following list describes the operations ..." would be better. > > 5.3.1. > > =A0 A UA wanting to place a call but not have an appearance number > =A0 assigned publishes before sending the INVITE without an 'appearance' > =A0 element but with the 'shared' event package parameter present. > > I think I understand what was intended here, but this would be clearer > if "publishes" was replaced with language about sending a PUBLISH. > It's also not completely clear whether "without" applies to the > INVITE or the PUBLISH, so this sentence probably needs to be reworded. OK, it is the PUBLISH that doesn't have the parameter - I'll make this clea= r. > > 5.4. - Expand B2BUA acronym on first use. > > idnits 2.12.13 ran clean. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > From david.black@emc.com Fri Jun 29 06:44:21 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C061721F86FD; Fri, 29 Jun 2012 06:44:21 -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, 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 qImnSoaOKl70; Fri, 29 Jun 2012 06:44:20 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id C57C321F86C2; Fri, 29 Jun 2012 06:44:19 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5TDi7fv003111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 09:44:16 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 29 Jun 2012 09:43:57 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5TDht9Y008133; Fri, 29 Jun 2012 09:43:56 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Fri, 29 Jun 2012 09:43:55 -0400 From: To: Date: Fri, 29 Jun 2012 09:43:54 -0400 Thread-Topic: Gen-ART review of draft-ietf-bliss-shared-appearances-11 Thread-Index: Ac1Vk1H5siVBJynsTLy55SYGzR+w1QAZ0lZQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3A89C@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208D3A7FD@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mohsen.soroush@sylantro.com, ietf@ietf.org, gen-art@ietf.org, bliss@ietf.org, david.black@emc.com Subject: Re: [BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-11 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 13:44:22 -0000 Alan, Thank you for the quick response. I have a few comments on the proposed resolutions. Absence of a comment implies that I agree with the proposed resolution. REQ-16 - I understand what's going on here (automatic ringdown), but the language is just slightly off because there is actually a dialing request. Here's all of REQ-16: REQ-16 The mechanism should support a way for a UA to seize a particular appearance number and also send the request at the same time. This is needed when an automatic ringdown feature (a telephone configured to immediately dial a phone number when it goes off hook) is combined with shared appearances - in this case, seizing the line is the same thing as dialing. The language problem is that the line seizing includes a dialing request, so "is the same thing as" isn't quite correct when applied solely to "seizing the line". As you suggest, the simplest fix would be to just remove "- in this case ... dialing", or it could be changed to: - in this case, seizing the line is part of dialing. 5.3 - Doing nothing is fine. I'm not a SIP expert, so I assume that the standard PUBLISH behavior (soft-state times out if not refreshed) is well-known to anyone who is, and hence no change is needed. 5.4 - please add "(Bad Request)" after each of the two instances of "400". 9.1/2/3 - please change to using "SHOULD" in each of these sections and explain that the "SHOULD" is motivated by user experience concerns. Thanks, --David > -----Original Message----- > From: Alan Johnston [mailto:alan.b.johnston@gmail.com] > Sent: Thursday, June 28, 2012 9:05 PM > To: Black, David > Cc: mohsen.soroush@sylantro.com; vvenkatar@gmail.com; gen-art@ietf.org; > shida@ntt-at.com; bliss@ietf.org; ietf@ietf.org; rjsparks@nostrum.com > Subject: Re: Gen-ART review of draft-ietf-bliss-shared-appearances-11 >=20 > David, >=20 > Thank you for your review of the document. =A0See below for how I > propose to resolve the issues you have raised. Let me know if you > have any other issues or concerns. >=20 > - Alan - >=20 > On Thu, Jun 28, 2012 at 3:51 PM, wrote: > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > . > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > Document: draft-ietf-bliss-shared-appearances-11 > > Reviewer: David L. Black > > Review Date: June 28, 2012 > > IETF LC End Date: June 28, 2012 > > IESG Telechat date: (if known) > > > > Summary: > > > > This draft is on the right track but has open issues, described in the > review. > > > > This draft describes support for shared appearances in support of multi= -line > > and shared-line telephone often found in businesses. =A0All of the open= issues > > are minor. =A0The draft is well-written and reasonably clear for the mo= st > part, > > although significant SIP expertise is required to completely understand= it. > > > > Major issues: =A0None. > > > > Minor issues: > > > > 4.1 - REQ-16: > > > > =A0 in this case, seizing the line is the same thing as dialing. > > > > That seems wrong - I would have thought it was a "prerequisite" as > > opposed to "the same thing" because seizing the line is immediately > > followed by a dialing request. >=20 >=20 > This requirement is about sending one request that causes both actions > to occur. =A0In a PSTN ringdown circuit (a very specialized circuit, > used for "hotlines"), the two operations are the same thing. =A0Besides > this statement, is REQ-16 itself not clear? =A0Perhaps I should just > remove this statement if it adds confusion rather than clarity to the > requirement. >=20 > > > > > > 5.3. > > > > =A0 A user may select an appearance number but then abandon placing a > > =A0 call (go back on hook). =A0In this case, the UA MUST free up the > > =A0 appearance number by removing the event state with a PUBLISH as > > =A0 described in [RFC3903]. > > > > What happens when that can't be done due to UA or network failure? >=20 >=20 > A little further down in this section says: >=20 > "=A0 This publication state is refreshed as described in [RFC3903] during > =A0 =A0the early dialog state or the Appearance Agent may reassign the > =A0 =A0appearance number." >=20 > So if the removal publish is lost, it will eventually timeout since it > is not refreshed. This is standard PUBLISH behavior described in RFC > 3903. >=20 > > > > > > 5.4. > > > > =A0 A 400 response is returned if the chosen appearance number is inval= id, > > > > Is that always a 400 (Bad Request) or is any 4xx response allowed? =A0I= f > > it's always 400, add the words "Bad Request" after "400". >=20 > We chose 400 in particular, although any 4xx response would have the > same result. "Bad Request" is the reason phrase, and the practice of > putting it in () is a convention commonly used in SIP documents. The > actual reason phrase can be different, customized ("Invalid > Appearance") if desired, or in a different language. >=20 > So in this case we are specifying the 400 response. >=20 > > > > =A0 If the Appearance Agent policy does not allow this, a 400 response > > =A0 is returned. > > > > Same question. =A0In addition, is 403 Forbidden allowed here? >=20 > 403 is usually used in SIP to indicate that the request has failed due > to an authorization policy, and the request can be retried with > different credentials. That doesn't quite fit here. >=20 > > > > =A0 If an INVITE is sent by a member of the group to the shared AOR (i.= e. > > =A0 they call their own AOR), the Appearance Agent MUST assign two > > =A0 appearance numbers. =A0The first appearance number will be the one > > =A0 selected or assigned to the outgoing INVITE. =A0The second appearan= ce > > =A0 number will be another one assigned by the Appearance Agent for the > > =A0 INVITE as it is forked back to the members of the group. > > > > How does that interact with the single appearance UAs in 8.1.1 that won= 't > > understand the second appearance number? =A0A warning that such a UA ca= n't > > pick up its call to its own AOR would suffice, either here or in 8.1.1. >=20 > I will put text in 8.1.1 that makes this point clear. >=20 > > > > 9.1 > > > > =A0 A UA that has no knowledge of appearances must will only have > > =A0 appearance numbers for outgoing calls if assigned by the Appearance > > =A0 Agent. =A0If the non-shared appearance UA does not support Join or > > =A0 Replaces, all dialogs could be marked "exclusive" to indicate that > > =A0 these options are not available. > > > > Should that "could be marked" be changed to "SHOULD be marked" ? > > Also, analogous questions for "could" in 9.2 and "can" in 9.3. > > > > All three of these affect interoperability. >=20 > I can change this to SHOULD. Actually, it doesn't affect > interoperability, as "exclusive" is just a hint, for user experience > and interface purposes and to reduce failed requests. If a Join or > Replace is inadvertently sent, the operation will fail, which is the > same result as not allowing it, although a worse user experience. >=20 > > > > 12. Security Considerations > > > > In general, this section is weak on rationale - the second, third and > > fourth paragraphs should all explain more about the purpose of and/or > > rationale for their security requirements (e.g., what does the security > > mechanism protect against and when/why might that protection be desired > > and/or required?). >=20 > Right, the mechanisms are to provide privacy and to prevent > hijacking/spoofing. I can add text to make this clear. >=20 > > > > =A0 NOTIFY or PUBLISH message bodies that provide the dialog state > > =A0 information and the dialog identifiers MAY be encrypted end-to-end > > =A0 using the standard mechanisms. > > > > What are "the standard mechanisms"? =A0List them, and provide reference= s, > > please. >=20 > That would be S/MIME as described in RFC 3261. I can add this. >=20 > > > > Please ensure that the section 6 XML and Section 7 ABNF are > > syntax-checked with actual tools. >=20 > I will double check them. >=20 > > > > Nits/editorial comments: > > > > p.10: > > > > =A0 The next section discusses the operations used to implement parts o= f > > =A0 the shared appearance feature. > > > > "The following list describes the operations ..." would be better. > > > > 5.3.1. > > > > =A0 A UA wanting to place a call but not have an appearance number > > =A0 assigned publishes before sending the INVITE without an 'appearance= ' > > =A0 element but with the 'shared' event package parameter present. > > > > I think I understand what was intended here, but this would be clearer > > if "publishes" was replaced with language about sending a PUBLISH. > > It's also not completely clear whether "without" applies to the > > INVITE or the PUBLISH, so this sentence probably needs to be reworded. >=20 > OK, it is the PUBLISH that doesn't have the parameter - I'll make this cl= ear. >=20 > > > > 5.4. - Expand B2BUA acronym on first use. > > > > idnits 2.12.13 ran clean. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > From alan.b.johnston@gmail.com Fri Jun 29 07:17:34 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2B321F86AA; Fri, 29 Jun 2012 07:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 x0AvZ4aVtn+E; Fri, 29 Jun 2012 07:17:30 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7065A21F86FD; Fri, 29 Jun 2012 07:17:30 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3073815ggn.31 for ; Fri, 29 Jun 2012 07:17:29 -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:content-transfer-encoding; bh=dk6H41O8IvIbdLLnP6a+MzMcMIdN1t9ODZg1cOjbDKE=; b=wZDaqviHB5hTcIhpHo1c7UkLyVe1ocVISo/6LELVU5hnz8qzUBKfLpFeC9KuEgAO/n HPMbTfr4InlK0o/9v3kX7RUfPmzVzx4Lpx9YBP34tD7RkOXE9zRdFTgxo5NjT6c9tpBa Gd+TvmbZ/ZgEAUeSTMpHShrmu+HSWETScJFq+yrYIq9+hWqC3ibjgd6UiuZRZ5PPPci1 sR/M6c1DgGxlKWeyDcrz7mbJijNWcCB4+3g9PiOiL3wjY/bqU/WJK//qbRDB+iDXDPSE 1MmtuSZIVmVGrUemaSXg7gwS7qd2vUPBHh8iAnRJ3s4ZTyk/4dfIXQa38JseB0OwL0Ss 5MOQ== MIME-Version: 1.0 Received: by 10.50.193.196 with SMTP id hq4mr1555160igc.57.1340979449458; Fri, 29 Jun 2012 07:17:29 -0700 (PDT) Received: by 10.231.228.135 with HTTP; Fri, 29 Jun 2012 07:17:29 -0700 (PDT) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208D3A89C@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208D3A7FD@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71208D3A89C@MX15A.corp.emc.com> Date: Fri, 29 Jun 2012 09:17:29 -0500 Message-ID: From: Alan Johnston To: david.black@emc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mohsen.soroush@sylantro.com, ietf@ietf.org, gen-art@ietf.org, bliss@ietf.org Subject: Re: [BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-11 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 14:17:35 -0000 David, I will make those changes. Thanks for the feedback. - Alan - On Fri, Jun 29, 2012 at 8:43 AM, wrote: > Alan, > > Thank you for the quick response. =A0I have a few comments on the propose= d > resolutions. =A0Absence of a comment implies that I agree with the propos= ed > resolution. > > REQ-16 - I understand what's going on here (automatic ringdown), but the > language is just slightly off because there is actually a dialing request= . > Here's all of REQ-16: > > =A0 REQ-16 The mechanism should support a way for a UA to seize a > =A0 particular appearance number and also send the request at the same > =A0 time. =A0This is needed when an automatic ringdown feature (a telepho= ne > =A0 configured to immediately dial a phone number when it goes off hook) > =A0 is combined with shared appearances - in this case, seizing the line > =A0 is the same thing as dialing. > > The language problem is that the line seizing includes a dialing request, > so "is the same thing as" isn't quite correct when applied solely to > "seizing the line". =A0As you suggest, the simplest fix would be to just > remove "- in this case ... dialing", or it could be changed to: > > =A0 =A0 =A0 =A0- in this case, seizing the line is part of dialing. > > 5.3 - Doing nothing is fine. =A0I'm not a SIP expert, so I assume that > the standard PUBLISH behavior (soft-state times out if not refreshed) > is well-known to anyone who is, and hence no change is needed. > > 5.4 - please add "(Bad Request)" after each of the two instances of "400"= . > > 9.1/2/3 - please change to using "SHOULD" in each of these sections > and explain that the "SHOULD" is motivated by user experience concerns. > > Thanks, > --David > >> -----Original Message----- >> From: Alan Johnston [mailto:alan.b.johnston@gmail.com] >> Sent: Thursday, June 28, 2012 9:05 PM >> To: Black, David >> Cc: mohsen.soroush@sylantro.com; vvenkatar@gmail.com; gen-art@ietf.org; >> shida@ntt-at.com; bliss@ietf.org; ietf@ietf.org; rjsparks@nostrum.com >> Subject: Re: Gen-ART review of draft-ietf-bliss-shared-appearances-11 >> >> David, >> >> Thank you for your review of the document. =A0See below for how I >> propose to resolve the issues you have raised. =A0Let me know if you >> have any other issues or concerns. >> >> - Alan - >> >> On Thu, Jun 28, 2012 at 3:51 PM, wrote: >> > >> > I am the assigned Gen-ART reviewer for this draft. For background on >> > Gen-ART, please see the FAQ at >> > . >> > >> > Please resolve these comments along with any other Last Call comments >> > you may receive. >> > >> > Document: draft-ietf-bliss-shared-appearances-11 >> > Reviewer: David L. Black >> > Review Date: June 28, 2012 >> > IETF LC End Date: June 28, 2012 >> > IESG Telechat date: (if known) >> > >> > Summary: >> > >> > This draft is on the right track but has open issues, described in the >> review. >> > >> > This draft describes support for shared appearances in support of mult= i-line >> > and shared-line telephone often found in businesses. =A0All of the ope= n issues >> > are minor. =A0The draft is well-written and reasonably clear for the m= ost >> part, >> > although significant SIP expertise is required to completely understan= d it. >> > >> > Major issues: =A0None. >> > >> > Minor issues: >> > >> > 4.1 - REQ-16: >> > >> > =A0 in this case, seizing the line is the same thing as dialing. >> > >> > That seems wrong - I would have thought it was a "prerequisite" as >> > opposed to "the same thing" because seizing the line is immediately >> > followed by a dialing request. >> >> >> This requirement is about sending one request that causes both actions >> to occur. =A0In a PSTN ringdown circuit (a very specialized circuit, >> used for "hotlines"), the two operations are the same thing. =A0Besides >> this statement, is REQ-16 itself not clear? =A0Perhaps I should just >> remove this statement if it adds confusion rather than clarity to the >> requirement. >> >> > >> > >> > 5.3. >> > >> > =A0 A user may select an appearance number but then abandon placing a >> > =A0 call (go back on hook). =A0In this case, the UA MUST free up the >> > =A0 appearance number by removing the event state with a PUBLISH as >> > =A0 described in [RFC3903]. >> > >> > What happens when that can't be done due to UA or network failure? >> >> >> A little further down in this section says: >> >> "=A0 This publication state is refreshed as described in [RFC3903] durin= g >> =A0 =A0the early dialog state or the Appearance Agent may reassign the >> =A0 =A0appearance number." >> >> So if the removal publish is lost, it will eventually timeout since it >> is not refreshed. =A0This is standard PUBLISH behavior described in RFC >> 3903. >> >> > >> > >> > 5.4. >> > >> > =A0 A 400 response is returned if the chosen appearance number is inva= lid, >> > >> > Is that always a 400 (Bad Request) or is any 4xx response allowed? =A0= If >> > it's always 400, add the words "Bad Request" after "400". >> >> We chose 400 in particular, although any 4xx response would have the >> same result. =A0"Bad Request" is the reason phrase, and the practice of >> putting it in () is a convention commonly used in SIP documents. =A0The >> actual reason phrase can be different, customized ("Invalid >> Appearance") if desired, or in a different language. >> >> So in this case we are specifying the 400 response. >> >> > >> > =A0 If the Appearance Agent policy does not allow this, a 400 response >> > =A0 is returned. >> > >> > Same question. =A0In addition, is 403 Forbidden allowed here? >> >> 403 is usually used in SIP to indicate that the request has failed due >> to an authorization policy, and the request can be retried with >> different credentials. =A0That doesn't quite fit here. >> >> > >> > =A0 If an INVITE is sent by a member of the group to the shared AOR (i= .e. >> > =A0 they call their own AOR), the Appearance Agent MUST assign two >> > =A0 appearance numbers. =A0The first appearance number will be the one >> > =A0 selected or assigned to the outgoing INVITE. =A0The second appeara= nce >> > =A0 number will be another one assigned by the Appearance Agent for th= e >> > =A0 INVITE as it is forked back to the members of the group. >> > >> > How does that interact with the single appearance UAs in 8.1.1 that wo= n't >> > understand the second appearance number? =A0A warning that such a UA c= an't >> > pick up its call to its own AOR would suffice, either here or in 8.1.1= . >> >> I will put text in 8.1.1 that makes this point clear. >> >> > >> > 9.1 >> > >> > =A0 A UA that has no knowledge of appearances must will only have >> > =A0 appearance numbers for outgoing calls if assigned by the Appearanc= e >> > =A0 Agent. =A0If the non-shared appearance UA does not support Join or >> > =A0 Replaces, all dialogs could be marked "exclusive" to indicate that >> > =A0 these options are not available. >> > >> > Should that "could be marked" be changed to "SHOULD be marked" ? >> > Also, analogous questions for "could" in 9.2 and "can" in 9.3. >> > >> > All three of these affect interoperability. >> >> I can change this to SHOULD. =A0Actually, it doesn't affect >> interoperability, as "exclusive" is just a hint, for user experience >> and interface purposes and to reduce failed requests. =A0If a Join or >> Replace is inadvertently sent, the operation will fail, which is the >> same result as not allowing it, although a worse user experience. >> >> > >> > 12. Security Considerations >> > >> > In general, this section is weak on rationale - the second, third and >> > fourth paragraphs should all explain more about the purpose of and/or >> > rationale for their security requirements (e.g., what does the securit= y >> > mechanism protect against and when/why might that protection be desire= d >> > and/or required?). >> >> Right, the mechanisms are to provide privacy and to prevent >> hijacking/spoofing. =A0I can add text to make this clear. >> >> > >> > =A0 NOTIFY or PUBLISH message bodies that provide the dialog state >> > =A0 information and the dialog identifiers MAY be encrypted end-to-end >> > =A0 using the standard mechanisms. >> > >> > What are "the standard mechanisms"? =A0List them, and provide referenc= es, >> > please. >> >> That would be S/MIME as described in RFC 3261. =A0I can add this. >> >> > >> > Please ensure that the section 6 XML and Section 7 ABNF are >> > syntax-checked with actual tools. >> >> I will double check them. >> >> > >> > Nits/editorial comments: >> > >> > p.10: >> > >> > =A0 The next section discusses the operations used to implement parts = of >> > =A0 the shared appearance feature. >> > >> > "The following list describes the operations ..." would be better. >> > >> > 5.3.1. >> > >> > =A0 A UA wanting to place a call but not have an appearance number >> > =A0 assigned publishes before sending the INVITE without an 'appearanc= e' >> > =A0 element but with the 'shared' event package parameter present. >> > >> > I think I understand what was intended here, but this would be clearer >> > if "publishes" was replaced with language about sending a PUBLISH. >> > It's also not completely clear whether "without" applies to the >> > INVITE or the PUBLISH, so this sentence probably needs to be reworded. >> >> OK, it is the PUBLISH that doesn't have the parameter - I'll make this c= lear. >> >> > >> > 5.4. - Expand B2BUA acronym on first use. >> > >> > idnits 2.12.13 ran clean. >> > >> > Thanks, >> > --David >> > ---------------------------------------------------- >> > David L. Black, Distinguished Engineer >> > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 >> > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 29= 3-7786 >> > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 >> > ---------------------------------------------------- >> > > From dworley@avaya.com Fri Jun 29 12:18:33 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B0C21F8865; Fri, 29 Jun 2012 12:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.952 X-Spam-Level: X-Spam-Status: No, score=-102.952 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 D2sT0e2dOwwG; Fri, 29 Jun 2012 12:18:32 -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 D1EF821F87EC; Fri, 29 Jun 2012 12:18:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIj+7U+HCzI1/2dsb2JhbABFhVqvXoEegQeCGAEBAQEDEhERRRACAQgNCwICJgICAjAVEAEBBA4NGodpnnqKHpMggSCPDzJgA5sriguCew X-IronPort-AV: E=Sophos;i="4.77,499,1336363200"; d="scan'208";a="313255578" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 Jun 2012 15:15:55 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 29 Jun 2012 14:59:49 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Fri, 29 Jun 2012 15:18:28 -0400 From: "Worley, Dale R (Dale)" To: "alan.b.johnston@gmail.com" Date: Fri, 29 Jun 2012 15:18:24 -0400 Thread-Topic: Gen-ART review of draft-ietf-bliss-shared-appearances-11 Thread-Index: Ac1WK/SS5AOXm0ZpSfqMaQa/q754dw== Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71208D3A7FD@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mohsen.soroush@sylantro.com" , "ietf@ietf.org" , "gen-art@ietf.org" , "bliss@ietf.org" , "david.black@emc.com" Subject: Re: [BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-11 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 19:18:33 -0000 T24gVGh1LCAyMDEyLTA2LTI4IGF0IDIwOjA1IC0wNTAwLCBBbGFuIEpvaG5zdG9uIHdyb3RlOgo+ ID4KPiA+IDQuMSAtIFJFUS0xNjoKPiA+Cj4gPiAgIGluIHRoaXMgY2FzZSwgc2VpemluZyB0aGUg bGluZSBpcyB0aGUgc2FtZSB0aGluZyBhcyBkaWFsaW5nLgo+ID4KPiA+IFRoYXQgc2VlbXMgd3Jv bmcgLSBJIHdvdWxkIGhhdmUgdGhvdWdodCBpdCB3YXMgYSAicHJlcmVxdWlzaXRlIiBhcwo+ID4g b3Bwb3NlZCB0byAidGhlIHNhbWUgdGhpbmciIGJlY2F1c2Ugc2VpemluZyB0aGUgbGluZSBpcyBp bW1lZGlhdGVseQo+ID4gZm9sbG93ZWQgYnkgYSBkaWFsaW5nIHJlcXVlc3QuCj4gCj4gCj4gVGhp cyByZXF1aXJlbWVudCBpcyBhYm91dCBzZW5kaW5nIG9uZSByZXF1ZXN0IHRoYXQgY2F1c2VzIGJv dGggYWN0aW9ucwo+IHRvIG9jY3VyLiAgSW4gYSBQU1ROIHJpbmdkb3duIGNpcmN1aXQgKGEgdmVy eSBzcGVjaWFsaXplZCBjaXJjdWl0LAo+IHVzZWQgZm9yICJob3RsaW5lcyIpLCB0aGUgdHdvIG9w ZXJhdGlvbnMgYXJlIHRoZSBzYW1lIHRoaW5nLiAgQmVzaWRlcwo+IHRoaXMgc3RhdGVtZW50LCBp cyBSRVEtMTYgaXRzZWxmIG5vdCBjbGVhcj8gIFBlcmhhcHMgSSBzaG91bGQganVzdAo+IHJlbW92 ZSB0aGlzIHN0YXRlbWVudCBpZiBpdCBhZGRzIGNvbmZ1c2lvbiByYXRoZXIgdGhhbiBjbGFyaXR5 IHRvIHRoZQo+IHJlcXVpcmVtZW50LgoKSU1ITywgYSBnb29kIGZpeCBpczoKCiAgIFJFUS0xNiBU aGUgbWVjaGFuaXNtIHNob3VsZCBzdXBwb3J0IGEgd2F5IGZvciBhIFVBIHRvIHNlaXplIGEKICAg cGFydGljdWxhciBhcHBlYXJhbmNlIG51bWJlciBhbmQgYWxzbyBzZW5kIHRoZSByZXF1ZXN0IGF0 IHRoZSBzYW1lCiAgIHRpbWUuICBUaGlzIGlzIG5lZWRlZCB3aGVuIGFuIGF1dG9tYXRpYyByaW5n ZG93biBmZWF0dXJlIChhIHRlbGVwaG9uZQogICBjb25maWd1cmVkIHRvIGltbWVkaWF0ZWx5IGRp YWwgYSBwaG9uZSBudW1iZXIgd2hlbiBpdCBnb2VzIG9mZiBob29rKQogICBpcyBjb21iaW5lZCB3 aXRoIHNoYXJlZCBhcHBlYXJhbmNlcyAtIGluIHRoaXMgY2FzZSwgc2VpemluZyB0aGUgbGluZQog ICBpcyA+Pj5pbnRlZ3JhdGVkIHdpdGg8PDwgZGlhbGluZy4KCkRhbGUKCg== From david.black@emc.com Fri Jun 29 12:23:43 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E6521F88A3; Fri, 29 Jun 2012 12:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, 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 n8KxSv8lk2DY; Fri, 29 Jun 2012 12:23:42 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6A42821F889A; Fri, 29 Jun 2012 12:23:42 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5TJNYLU021288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 15:23:35 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 29 Jun 2012 15:23:17 -0400 Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5TJNHdw022925; Fri, 29 Jun 2012 15:23:17 -0400 Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub34.corp.emc.com ([::1]) with mapi; Fri, 29 Jun 2012 15:23:16 -0400 From: To: , Date: Fri, 29 Jun 2012 15:23:15 -0400 Thread-Topic: Gen-ART review of draft-ietf-bliss-shared-appearances-11 Thread-Index: Ac1WK/SS5AOXm0ZpSfqMaQa/q754dwAAIaQQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3A9A0@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71208D3A7FD@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: mohsen.soroush@sylantro.com, ietf@ietf.org, gen-art@ietf.org, bliss@ietf.org, david.black@emc.com Subject: Re: [BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-11 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 19:23:44 -0000 VGhhdCB3b3JrcyBmb3IgbWUsIFRoYW5rcywgLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IFdvcmxleSwgRGFsZSBSIChEYWxlKSBbbWFpbHRvOmR3b3JsZXlA YXZheWEuY29tXQ0KPiBTZW50OiBGcmlkYXksIEp1bmUgMjksIDIwMTIgMzoxOCBQTQ0KPiBUbzog YWxhbi5iLmpvaG5zdG9uQGdtYWlsLmNvbQ0KPiBDYzogQmxhY2ssIERhdmlkOyBtb2hzZW4uc29y b3VzaEBzeWxhbnRyby5jb207IGlldGZAaWV0Zi5vcmc7IGdlbi0NCj4gYXJ0QGlldGYub3JnOyBi bGlzc0BpZXRmLm9yZzsgdnZlbmthdGFyQGdtYWlsLmNvbQ0KPiBTdWJqZWN0OiBSZTogR2VuLUFS VCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ibGlzcy1zaGFyZWQtYXBwZWFyYW5jZXMtMTENCj4gDQo+ IE9uIFRodSwgMjAxMi0wNi0yOCBhdCAyMDowNSAtMDUwMCwgQWxhbiBKb2huc3RvbiB3cm90ZToN Cj4gPiA+DQo+ID4gPiA0LjEgLSBSRVEtMTY6DQo+ID4gPg0KPiA+ID4gICBpbiB0aGlzIGNhc2Us IHNlaXppbmcgdGhlIGxpbmUgaXMgdGhlIHNhbWUgdGhpbmcgYXMgZGlhbGluZy4NCj4gPiA+DQo+ ID4gPiBUaGF0IHNlZW1zIHdyb25nIC0gSSB3b3VsZCBoYXZlIHRob3VnaHQgaXQgd2FzIGEgInBy ZXJlcXVpc2l0ZSIgYXMNCj4gPiA+IG9wcG9zZWQgdG8gInRoZSBzYW1lIHRoaW5nIiBiZWNhdXNl IHNlaXppbmcgdGhlIGxpbmUgaXMgaW1tZWRpYXRlbHkNCj4gPiA+IGZvbGxvd2VkIGJ5IGEgZGlh bGluZyByZXF1ZXN0Lg0KPiA+DQo+ID4NCj4gPiBUaGlzIHJlcXVpcmVtZW50IGlzIGFib3V0IHNl bmRpbmcgb25lIHJlcXVlc3QgdGhhdCBjYXVzZXMgYm90aCBhY3Rpb25zDQo+ID4gdG8gb2NjdXIu ICBJbiBhIFBTVE4gcmluZ2Rvd24gY2lyY3VpdCAoYSB2ZXJ5IHNwZWNpYWxpemVkIGNpcmN1aXQs DQo+ID4gdXNlZCBmb3IgImhvdGxpbmVzIiksIHRoZSB0d28gb3BlcmF0aW9ucyBhcmUgdGhlIHNh bWUgdGhpbmcuICBCZXNpZGVzDQo+ID4gdGhpcyBzdGF0ZW1lbnQsIGlzIFJFUS0xNiBpdHNlbGYg bm90IGNsZWFyPyAgUGVyaGFwcyBJIHNob3VsZCBqdXN0DQo+ID4gcmVtb3ZlIHRoaXMgc3RhdGVt ZW50IGlmIGl0IGFkZHMgY29uZnVzaW9uIHJhdGhlciB0aGFuIGNsYXJpdHkgdG8gdGhlDQo+ID4g cmVxdWlyZW1lbnQuDQo+IA0KPiBJTUhPLCBhIGdvb2QgZml4IGlzOg0KPiANCj4gICAgUkVRLTE2 IFRoZSBtZWNoYW5pc20gc2hvdWxkIHN1cHBvcnQgYSB3YXkgZm9yIGEgVUEgdG8gc2VpemUgYQ0K PiAgICBwYXJ0aWN1bGFyIGFwcGVhcmFuY2UgbnVtYmVyIGFuZCBhbHNvIHNlbmQgdGhlIHJlcXVl c3QgYXQgdGhlIHNhbWUNCj4gICAgdGltZS4gIFRoaXMgaXMgbmVlZGVkIHdoZW4gYW4gYXV0b21h dGljIHJpbmdkb3duIGZlYXR1cmUgKGEgdGVsZXBob25lDQo+ICAgIGNvbmZpZ3VyZWQgdG8gaW1t ZWRpYXRlbHkgZGlhbCBhIHBob25lIG51bWJlciB3aGVuIGl0IGdvZXMgb2ZmIGhvb2spDQo+ICAg IGlzIGNvbWJpbmVkIHdpdGggc2hhcmVkIGFwcGVhcmFuY2VzIC0gaW4gdGhpcyBjYXNlLCBzZWl6 aW5nIHRoZSBsaW5lDQo+ICAgIGlzID4+PmludGVncmF0ZWQgd2l0aDw8PCBkaWFsaW5nLg0KPiAN Cj4gRGFsZQ0KDQo= From alan.b.johnston@gmail.com Fri Jun 29 17:43:05 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E2721F849A; Fri, 29 Jun 2012 17:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 hTu8so4Rqnni; Fri, 29 Jun 2012 17:43:05 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E510E21F844B; Fri, 29 Jun 2012 17:43:04 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4968301obb.31 for ; Fri, 29 Jun 2012 17:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=eF5yYxdrm0swAjP9jGXQF5kDnPRhZ5N4RqNg9kmEaAg=; b=lmI3kN/oGVrNVHkFcngn92r1j6nz79rYUHZ9LmTrY6z+izKqaavsbSu4mkkSS9p7Lh UFbT681uPb65ttObCQhOgHSOPHhBicGul30lCpfNhOcwO2sv1mFA7el3R6KSD5SBBQeh 82KbdsDeR/2Sf+IO6c62aNkRpmKS5j/0BX/DsrQxL1yqFjFztzw7SP+e974xFg1EDaEC 3M7AAlmzkCLX+Z/P0zDMfmaBE7D1X1dw1Bk1Wb11ii2J5K9BWv2rXwhUjr9yLb7vfIsS 9yqKFUzTnlqxfbdsm3NoH3OLstuFflkXYa3sdoAiXuAsuLzaabi84CtDU0eYnx2wpE20 Vesw== Received: by 10.60.21.198 with SMTP id x6mr2034683oee.24.1341016898396; Fri, 29 Jun 2012 17:41:38 -0700 (PDT) Received: from [10.4.153.20] (mobile-166-147-069-169.mycingular.net. [166.147.69.169]) by mx.google.com with ESMTPS id n10sm4159930oeb.6.2012.06.29.17.41.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 17:41:37 -0700 (PDT) References: <8D3D17ACE214DC429325B2B98F3AE71208D3A7FD@MX15A.corp.emc.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <8CC36564-7A02-47AC-9BCA-4DE0C9BECADE@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9B206) From: Alan Johnston Date: Fri, 29 Jun 2012 19:41:28 -0500 To: "Worley, Dale R (Dale)" Cc: "mohsen.soroush@sylantro.com" , "ietf@ietf.org" , "gen-art@ietf.org" , "bliss@ietf.org" , "david.black@emc.com" Subject: Re: [BLISS] Gen-ART review of draft-ietf-bliss-shared-appearances-11 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 00:43:05 -0000 We will use this language. Thanks, Dale.=20 - Alan - On Jun 29, 2012, at 2:18 PM, "Worley, Dale R (Dale)" wro= te: > On Thu, 2012-06-28 at 20:05 -0500, Alan Johnston wrote: >>>=20 >>> 4.1 - REQ-16: >>>=20 >>> in this case, seizing the line is the same thing as dialing. >>>=20 >>> That seems wrong - I would have thought it was a "prerequisite" as >>> opposed to "the same thing" because seizing the line is immediately >>> followed by a dialing request. >>=20 >>=20 >> This requirement is about sending one request that causes both actions >> to occur. In a PSTN ringdown circuit (a very specialized circuit, >> used for "hotlines"), the two operations are the same thing. Besides >> this statement, is REQ-16 itself not clear? Perhaps I should just >> remove this statement if it adds confusion rather than clarity to the >> requirement. >=20 > IMHO, a good fix is: >=20 > REQ-16 The mechanism should support a way for a UA to seize a > particular appearance number and also send the request at the same > time. This is needed when an automatic ringdown feature (a telephone > configured to immediately dial a phone number when it goes off hook) > is combined with shared appearances - in this case, seizing the line > is >>>integrated with<<< dialing. >=20 > Dale >=20