Re: [dispatch] Announcing a MUC with RFC4575

Peter Saint-Andre <stpeter@stpeter.im> Mon, 22 April 2013 21:06 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815C921E804D for <dispatch@ietfa.amsl.com>; Mon, 22 Apr 2013 14:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.367
X-Spam-Level:
X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfq5VqfD8c5C for <dispatch@ietfa.amsl.com>; Mon, 22 Apr 2013 14:06:52 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DA64321E8045 for <dispatch@ietf.org>; Mon, 22 Apr 2013 14:06:51 -0700 (PDT)
Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D389E41026; Mon, 22 Apr 2013 15:17:38 -0600 (MDT)
Message-ID: <5175A669.7060805@stpeter.im>
Date: Mon, 22 Apr 2013 15:06:49 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Emil Ivov <emcho@jitsi.org>
References: <51744F5B.8010506@jitsi.org> <5175A133.5040309@stpeter.im> <5175A4B1.2030707@jitsi.org>
In-Reply-To: <5175A4B1.2030707@jitsi.org>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Announcing a MUC with RFC4575
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Apr 2013 21:06:58 -0000

On 4/22/13 2:59 PM, Emil Ivov wrote:
> 
> 
> On 22.04.13, 22:44, Peter Saint-Andre wrote:
>> On 4/21/13 2:43 PM, Emil Ivov wrote:
>>> Hey all,
>>>
>>> I have been looking at RFC4575 and wondering what the best way would be
>>> for a mixer to announce that a conference has an associated chatroom
>>> (e.g. an XMPP MUC) available at a certain address. This would allow UAs
>>> that support MUCs can join there too.
>>>
>>> From what I see the most reasonable way to do this would be a
>>> <conf-uri>, like this for example:
>>>
>>> <conf-uris>
>>>   <entry>
>>>    <uri>sip:conf545@h323.example.com</uri>
>>>    <display-text>TTI Bridge</display-text>
>>>    <purpose>participation</purpose>
>>>   </entry>
>>>   <entry>
>>>    <uri>xmpp:conf545@conference.example.com</uri>
>>>    <display-text>Multi-User Chat 545</display-text>
>>>    <purpose>impp-participation</purpose>
>>>   </entry>
>>> </conf-uris>
>>>
>>> Another option would be to use the same <entry> but place it ina a
>>> <service-uris> element instead:
>>>
>>> <service-uris>
>>>   <entry>
>>>    <uri>http://sharepoint/salesgroup/</uri>
>>>    <purpose>web-page</purpose>
>>>   </entry>
>>>   <entry>
>>>    <uri>xmpp:conf545@conference.example.com</uri>
>>>    <display-text>Multi-User Chat 545</display-text>
>>>    <purpose>impp-participation</purpose>
>>>   </entry>
>>> </service-uris>
>>>
>>> Does any of the above make sense? In case no other mechanism allows for
>>> the same thing in a simpler way, then could we maybe put one of the two
>>> on paper?
>>
>> Somehow "impp-participation" doesn't sound right to me.
> 
> That was just a stab really. I don't really have a preference for the
> name ... unless it would mean less overhead: if for example we could
> have just reused the "impp" purpose from draft-saintandre-impp-call-info
> then that would have been great. However, as you point out, it currently
> only applies to Call-Info and we would need another draft that looks
> pretty much the same way (like Rifaat suggested).
> 
>> What you're
>> talking about is a multiparty text conference that is associated with or
>> auxiliary to the main conference. It seems to me that the text
>> conference could be an XMPP MUC room, an IRC channel, an MSRP multiparty
>> chat session, etc.
> 
> Correct.
> 
>> So I would suggest something like "groupchat" (since
>> the primary purpose here is multiparty text chat, not one-to-one IM and
>> presence as they are traditionally understood).
> 
> Well, it seems to me that a URI with an "impp" purpose that has a 1-to-1
> relation with a conference can only be a group chat and it would also
> give us some uniformity in the naming conventions. But again, I don't
> really mind what the exact name would be as long as a name is defined.

The "impp" acronym goes back to the IMPP WG and its main output, RFC
2778 and RFC 2779, which talked about one-to-one IM and one-to-one
presence. IMHO groupchat / multiparty text conferencing / whatever you
want to call it is quite a different beast.

Peter