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: Saúl Ibarra Corretgé <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
- [Stox] On generating RFC4575 participants list ou… Saúl Ibarra Corretgé
- Re: [Stox] On generating RFC4575 participants lis… Peter Saint-Andre
- Re: [Stox] On generating RFC4575 participants lis… Saúl Ibarra Corretgé
- Re: [Stox] On generating RFC4575 participants lis… Saúl Ibarra Corretgé
- Re: [Stox] On generating RFC4575 participants lis… Peter Saint-Andre