[BLISS] Technical issues regarding draft-ietf-bliss-shared-appearances-07

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 14 April 2011 21:33 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: bliss@ietfc.amsl.com
Delivered-To: bliss@ietfc.amsl.com
Received: from localhost (localhost []) by ietfc.amsl.com (Postfix) with ESMTP id E48B4E08FD for <bliss@ietfc.amsl.com>; Thu, 14 Apr 2011 14:33:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.988
X-Spam-Status: No, score=-102.988 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfc.amsl.com []) (amavisd-new, port 10024) with ESMTP id NPo7Vq8kAPmf for <bliss@ietfc.amsl.com>; Thu, 14 Apr 2011 14:33:59 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com []) by ietfc.amsl.com (Postfix) with ESMTP id 26893E0705 for <bliss@ietf.org>; Thu, 14 Apr 2011 14:33:56 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAFMtcU2HCzI1/2dsb2JhbACmZXSkeQKZFoVhBJAM
X-IronPort-AV: E=Sophos;i="4.64,213,1301889600"; d="scan'208";a="274874970"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Apr 2011 17:33:55 -0400
X-IronPort-AV: E=Sophos;i="4.64,213,1301889600"; d="scan'208";a="639231128"
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Apr 2011 17:33:55 -0400
Received: from DC-US1MBEX4.global.avaya.com ([]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 14 Apr 2011 17:33:54 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "bliss@ietf.org" <bliss@ietf.org>
Date: Thu, 14 Apr 2011 17:33:12 -0400
Thread-Topic: Technical issues regarding draft-ietf-bliss-shared-appearances-07
Thread-Index: AQHL+uunlbt2P8z0FUiuIFKAC/5cNA==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22246BD3D2@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [BLISS] Technical issues regarding draft-ietf-bliss-shared-appearances-07
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 21:34:00 -0000

To extract the technical questions from the editorial ones in my

It seems to me that the open technical questions are:

* Is the latest decision that appearance numbers start with 0, rather
  than 1?

Starting the numbering from 0 would be cleaner, but the customers will
universally count from 1, so all UAs are going to have to present
appearance numbers 1, 2, 3, ....  If the appearance numbers in the
protocol start with 0, all UAs will have to translate, which will
inevitably lead to errors.

* Is there a default value for "exclusive"?  The schema doesn't show

Inevitably people will omit the <exclusive> element, so we need to
decide what the implicit value is.  For simplicity, this default
should probably be the effective value for UAs that publish non-shared
dialog events, as the schema doesn't seem to be able to make
<exclusive> mandatory.

* It's not clear why PUBLISH refreshes are not required after transition
  to the confirmed state, as RFC 3903 states that published data are
  soft-state with specified expiration time.  If this I-D intends to
  handle expiration differently from RFC 3903, this needs to be
  specified clearly.

I suggest that we not use PUBLISH in a way that is at all different
from RFC 3903 -- changes would make it impossible to use a general
PUBLISH toolkit as part of a SA UA.

* The specification requires the AA to reject proposed appearance
  number assignments by a 400 response with a particular reason
  phrase, "Appearance Number Conflict".

Making the reason phrase significant is contrary to all previous SIP
usage.  And using 400 (the generic failure message) to indicate a
specific meaning is hazardous.  Wouldn't it be better to allocate a
unique 4xx response code?  (There are over 50 available.)

* It would also be useful in practice if some hints were given for
  interoperation with UAs that implement previous versions of this

This probably can be limited to methods to detect which version a
particular UA implements.

* The description in section 11.8 says that a call from one UA in a
  group to another UA in the group would only use one appearance
  number.  This is not uniform with the rest of the SA architecture
  and is not the behavior of traditional key phone systems.

Are you sure you want to handle this call this way?