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

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 12 Dec 2013 10:24:02 +0100

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

--
Saúl Ibarra Corretgé
AG Projects

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 12 Dec 2013 06:41:30 -0700

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

Will do later today or tonight.

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

Me, neither.

Onward and upward! :-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/