[BLISS] bliss-MLA-req-01: Simpler <joined-dialog> approach

"Derek MacDonald" <derek@counterpath.com> Thu, 28 February 2008 23:18 UTC

Return-Path: <bliss-bounces@ietf.org>
X-Original-To: ietfarch-bliss-archive@core3.amsl.com
Delivered-To: ietfarch-bliss-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A259528C3CB; Thu, 28 Feb 2008 15:18:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.244
X-Spam-Level:
X-Spam-Status: No, score=0.244 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_93=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MofOZipa8f6x; Thu, 28 Feb 2008 15:18:26 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB39528C2AD; Thu, 28 Feb 2008 15:18:26 -0800 (PST)
X-Original-To: bliss@core3.amsl.com
Delivered-To: bliss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222C728C257 for <bliss@core3.amsl.com>; Thu, 28 Feb 2008 15:18:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcQr3xEQ9RZz for <bliss@core3.amsl.com>; Thu, 28 Feb 2008 15:18:20 -0800 (PST)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 2F36C28C4E9 for <bliss@ietf.org>; Thu, 28 Feb 2008 15:17:39 -0800 (PST)
Received: by wf-out-1314.google.com with SMTP id 25so3472556wfa.31 for <bliss@ietf.org>; Thu, 28 Feb 2008 15:17:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=zDum4C4TBc2r9mk5kBBl9xcw8twATbevQ5Ag4LnT8gc=; b=p6ZDt+3l0qgWiHa+ci/WdclUGELHZEcyqPLyHqzKeo1bwHT0wxzSEK1ea3VOGhALo99fGKqcKAf5NSC60kSkkzn/UXicIiTca47f0O5kVoc1Dg5SfZcdlAwZeWItLxLMt+ae2CLIQAC+w4bMRpG/+d35WU5IVP46l/4mljz+ktc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=i2xFuCTP//HVmJMlSIR4G2p9MrmxpHfD8Y0NvnnEhd1qAxJGC5n01hjpGjf0RW37zK3FThFjN41Fy7B2YSatc6WBfotdeezcNZrIK5xaiOCx/hi6S2aNK+79hRYozlaHsdTix6+zjPsJZSyygGEyWJhNy15HRgwfd+V9xSMKNvs=
Received: by 10.142.188.4 with SMTP id l4mr6670673wff.92.1204240651754; Thu, 28 Feb 2008 15:17:31 -0800 (PST)
Received: by 10.142.14.9 with HTTP; Thu, 28 Feb 2008 15:17:31 -0800 (PST)
Message-ID: <ef68b73f0802281517j259f1b71yd87d918a7b9ed52@mail.gmail.com>
Date: Thu, 28 Feb 2008 15:17:31 -0800
From: Derek MacDonald <derek@counterpath.com>
To: bliss@ietf.org
MIME-Version: 1.0
Content-Disposition: inline
X-Google-Sender-Auth: 1499a62e9b93c4dd
Subject: [BLISS] bliss-MLA-req-01: Simpler <joined-dialog> approach
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: bliss-bounces@ietf.org
Errors-To: bliss-bounces@ietf.org

Section 6.1.3 describes a <joined-dialog> element which uses the id
attribute of the dialog element to identity which dialogs are joined.
Unfortunately, the id attribute is only unique for a UA instance. This
requires that the state compositor MUST be prepared to offer different
notification documents(for the same dialog) for the UAs that have
conflicting id attributes.

An alternate approach would be to not use the id portion of the dialog
element to identity a joined dialog. It would still have call-id,
local-tag, remote-tag and direction. This eliminates the need for a
state compositor to provide different views; in fact, no composition
will be required within a dialog-info element.

I am not sure why we didn't do that in the first place.
Interestingly, I couldn't find any text in rfc4235 around id attribute
collisions.  It seems they lose meaning  when different UAs sharing an
aor are composed in a central state agent.

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