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

From: "Derek MacDonald" <[email-masked]>
Date: Thu, 28 Feb 2008 15:17:31 -0800

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
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Alan Johnston <[email-masked]>
Date: Thu, 28 Feb 2008 17:47:18 -0600

Derek,

It is already in the draft that way - I thought of this when I did the 
schema.

Thanks,
Alan

---

From: "Derek MacDonald" <[email-masked]>
Date: Thu, 28 Feb 2008 16:13:36 -0800

There is still some text in 6.3 which mentions dialog id conflicts; is
that just stray text?

-Derek

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 28 Feb 2008 19:51:43 -0600

Alan,

It appears that everything is in the draft. What do you propose to drive
this to an interoperable solution?

Thanks,

Martin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alan Johnston
Sent: Thursday, February 28, 2008 6:47 PM
To: Derek MacDonald
Cc: [email-masked]
Subject: Re: [BLISS] bliss-MLA-req-01: Simpler <joined-dialog> approach

Derek,

Thanks,
Alan

---

From: Alan Johnston <[email-masked]>
Date: Fri, 29 Feb 2008 08:01:30 -0600

Derek,

There is still a generic problem for a dialog event package event state 
compositor that puts together <dialog> elements from multiple UAs that 
the id attributes may not be unique.  This id is used for partial dialog 
updates, so it must be unique across all dialogs for an AOR, which is 
not what RFC 4235 says.  However, the specific problem relating to the 
new <joined-dialog> element isn't a problem any more.

I wonder if this is a bug in RFC 4235 or whether it is just a problem 
that event state compositors have to deal with.

Thanks,
Alan

---

From: Alan Johnston <[email-masked]>
Date: Fri, 29 Feb 2008 08:03:54 -0600

Martin,

We hope the document will be adopted as a BLISS working group item, 
first of all.  Then, we need to work on the new mechanisms to make sure 
we don't have any race conditions - some running code would be excellent 
for this.

I don't think we will need too many IETF cycles to move this document to 
be ready for last call.

Thanks,
Alan