Re: [Stox] Review of -chat

"Olle E. Johansson" <oej@edvina.net> Wed, 31 July 2013 15:09 UTC

Return-Path: <oej@edvina.net>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7668021F9E8B for <stox@ietfa.amsl.com>; Wed, 31 Jul 2013 08:09:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.793
X-Spam-Level:
X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_MLH_Stock1=0.87]
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 g2p2uGWN+jxl for <stox@ietfa.amsl.com>; Wed, 31 Jul 2013 08:09:08 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B1B8121F9E6C for <stox@ietf.org>; Wed, 31 Jul 2013 08:09:07 -0700 (PDT)
Received: from [IPv6:2001:df8::16:f490:4537:d80:d090] (unknown [IPv6:2001:df8:0:16:f490:4537:d80:d090]) by smtp7.webway.se (Postfix) with ESMTPA id D7F3B93C1AF; Wed, 31 Jul 2013 15:09:06 +0000 (UTC)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <CE5438E7-7587-4512-AE96-06CAF135D5CD@ag-projects.com>
Date: Wed, 31 Jul 2013 17:09:07 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E68FDA2-999A-4FF8-AB28-F182F85282C7@edvina.net>
References: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@ag-projects.com> <51F92121.6010902@stpeter.im> <CE5438E7-7587-4512-AE96-06CAF135D5CD@ag-projects.com>
To: Saúl Ibarra Corretgé <saul@ag-projects.com>
X-Mailer: Apple Mail (2.1508)
Cc: "stox@ietf.org" <stox@ietf.org>, Peter Saint-Andre <stpeter@stpeter.im>
Subject: Re: [Stox] Review of -chat
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 31 Jul 2013 15:09:08 -0000

31 jul 2013 kl. 16:52 skrev Saúl Ibarra Corretgé <saul@ag-projects.com>:

>>> 
>>> - What should a gateway do when it gets a message with XHTML-IM body?
>>> I guess send it with content-type text/html, but is there any
>>> translation required?
>> 
>> I know about the use of XHTML in XMPP, but I don't know much about the
>> use in SIP. Is there a profile of (X)HTML that most SIP entities implement?
>> 
> 
> SIP entities will implement text/html, can we use that?
Or recommend multipart/alternative if it's a downgrade?
Which document says that SIP Uas will support text/html?

> 
>>> - Section 4 mentions what should happen if no formal sessions are
>>> used, but doesn't say anything of the opposite. Should we say that
>>> those are out of the scope of this specification?
>> 
>> Precursors to this document talked about formal chat sessions in XMPP
>> (XEP-0155), however no clients support that model so I remove all of
>> that text. The first paragraph of Section 4 reflects the earlier specs.
>> I think we just need to remove a few words from Section 4...
>> 
>> OLD
>>  When an MSRP client sends messages through a gateway to an XMPP
>>  client that does not support formal sessinos, the order of events is
>>  as follows.
>> 
>> NEW
>>  When an MSRP client sends messages through a gateway to an XMPP
>>  client, the order of events is as follows.
>> 
> 
> Sounds good to me.
> 
>>> - I think we should define a mapping between XMPP chatstates
>>> (XEP-0085) and the iscomosing indication (RFC 3994) particularly, the
>>> "gone" state in XMPP should trigger a BYE on the SIP side, and vice
>>> versa.
>> 
>> Could you describe a bit why you think that would be useful? (You
>> explained it to me in person, but I think it would be helpful to discuss
>> it on the list so that it's in the records of the WG. And for the record
>> I am pretty sure I agree with you.)
>> 
> 
> For one, both SIP and XMPP clients usually implement typing indications so translating the semantics between the two is useful to get that information through. Now, as for the 'gone' state case, it's used by XMPP clients when the conversation is closed, so the other party can know that the window was closed on the other side and conversation has ended. Ending a conversation in SIP would mean sending a BYE, and this is particularly useful, because otherwise the SIP / MSRP session would stay up forever since there is no ending condition.
Is the closing window notification more than just closing window? Is the chat dead, really?

/O