Re: [Stox] On generating RFC4575 participants list out of a MUC

Saúl Ibarra Corretgé <saul@ag-projects.com> Thu, 12 December 2013 09:24 UTC

Return-Path: <saul@ag-projects.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218B31AE09D for <stox@ietfa.amsl.com>; Thu, 12 Dec 2013 01:24:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.389
X-Spam-Level:
X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maI3a3h958X3 for <stox@ietfa.amsl.com>; Thu, 12 Dec 2013 01:24:12 -0800 (PST)
Received: from mail3.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0AABF1AE208 for <stox@ietf.org>; Thu, 12 Dec 2013 01:24:11 -0800 (PST)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail3.sipthor.net (Postfix) with ESMTPSA id 07B9D14AC003; Thu, 12 Dec 2013 10:30:17 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
In-Reply-To: <52799DF7.9080803@stpeter.im>
Date: Thu, 12 Dec 2013 10:24:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C72EAFC5-62D8-40C7-A866-17714D6DEA11@ag-projects.com>
References: <1B5D6CBE-2151-4749-8A7C-8122B04BB071@ag-projects.com> <52799DF7.9080803@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1085)
Cc: stox@ietf.org
Subject: Re: [Stox] On generating RFC4575 participants list out of a MUC
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 09:24:14 -0000

I finally managed to update the goupchat draft with this :-)

It's on the IETF svn repo, can you take a look.

I don't have any other open issues on my list.


Cheers,

On Nov 6, 2013, at 2:40 AM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Saúl!
> 
> On 10/25/13 1:38 AM, Saúl Ibarra Corretgé wrote:
>> Hi all,
>> 
>> This is regarding the issue I mentioned at the meeting in Berlin
>> to which Peter referred recently.
>> 
>> In 4575 there are 2 types of entities which kind of relate to 
>> participants: users and endpoints. Each user contains a list of 
>> endpoints. As per the RFC:
>> 
>> - "The <users> element is a container of <user> child elements,
>> each describing a single participant in the conference."
>> 
>> - "By including one or more <endpoint> elements under a parent 
>> <user> element, the server can provide the desired level of detail
>> (including the state, media streams, and access information) about
>> the user's devices and signaling sessions taking part in the 
>> conference."
>> 
>> In SIP a user would be an AoR and an endpoint would be the contact
>> or GRUU.
>> 
>> In XMPP tough, things are a bit more complicated. In the beginning
>> I thought we could use the user bare JID as the <user> element and
>> the occupant JID as the <endpoint>, but in practice this is not
>> going to work, because the real JID is not always available in a
>> MUC.
>> 
>> So, considering that, here is how I propose we proceed:
>> 
>> - <user> element entity is the occupant JID - if the real JID is 
>> available, it MAY be added as a <associated-aors> child element of 
>> <user> (4575, sec 5.6.2) (based on local policy) - <endpoint>
>> entity is also the occupant JID
>> 
>> Neither user entity or endpoint entity is an xs:ID, so using it in 
>> both places doesn't invalidate the document :-)
>> 
>> Thoughts?
> 
> Your analysis looks reasonable to me, and I think that's the best we
> can do given the information that will usually be available in an XMPP
> multi-user chat room.
> 
> Peter
> 
> - -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJSeZ32AAoJEOoGpJErxa2pXOEQALM+zCq83LaE82YTP4Hzar/g
> Jd5zRksJdrj32yVX2sEvO2pF7Zmi+4lHN6NTlJ+y219pTox4sB+BPFK89viRjyG/
> J5tdfruQ9A4ugKV+DGw9l9ddO5od7CVvjwSqalBI+n0xApuC+acpLKspA7uuKsfu
> 4qRVborWHAm/FL0whklSDduBeFaaVFibH/OGEIRkf7vldTiNaGV0POsbDTx8uHlf
> 1eHYvonkeGYDTRcWC2/Ry6KBCFN2fN+s43PFqkaAHjIkDoFZNUGcx0enyAQ5TjUW
> tP3uniGrayVYbgcx2M4HYelkPJSCKAxXELJZODWEL8xKvFC5zsnsId9XqaY1iszf
> fiwDCjGoeUWDzrcxU7PWv4L+7MFCQmZv06EXphWBLEzDU05nNbHsBVBovlLyu88l
> bjGyg8+RJyOeh0F1l4zx0aiHV2EB4K7PshPsBG+kCSvx2ApFf9sKn6zAvECc0d//
> DAYYwjftD1v6gR5Fv2wlbN147xdWJKGTBtGFBC44P3+FyadZNj5wxD6Z0+kOESV8
> mbSlVNntJFE2T7Iw1Td2LtHj+aPaarxZ/6SL4xs0gMk7sOv366z1eHzmyPlBC24V
> NKuw0MzBfEwgLEXOL3u1LqLSII13+MnmqsBuyogBe+L9J/cN3rpOxtFN6r4XhPVp
> VReUows2wtCw6gyQ96CZ
> =Tmo1
> -----END PGP SIGNATURE-----
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox

--
Saúl Ibarra Corretgé
AG Projects