Re: [Stox] Review of -chat

Peter Saint-Andre <stpeter@stpeter.im> Wed, 31 July 2013 14:37 UTC

Return-Path: <stpeter@stpeter.im>
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 5B0A521E8125 for <stox@ietfa.amsl.com>; Wed, 31 Jul 2013 07:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.89
X-Spam-Level:
X-Spam-Status: No, score=-101.89 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87, 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 2Dh1odB6fLJ8 for <stox@ietfa.amsl.com>; Wed, 31 Jul 2013 07:37:30 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 08A2921F9A3C for <stox@ietf.org>; Wed, 31 Jul 2013 07:37:24 -0700 (PDT)
Received: from che-vpn-cluster-2-456.cisco.com (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E63D440046; Wed, 31 Jul 2013 08:39:38 -0600 (MDT)
Message-ID: <51F92121.6010902@stpeter.im>
Date: Wed, 31 Jul 2013 16:37:21 +0200
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
References: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@ag-projects.com>
In-Reply-To: <7F5BB54B-0650-42BA-A599-C5DBBB6326D4@ag-projects.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: "stox@ietf.org" <stox@ietf.org>
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 14:37:36 -0000

On 7/30/13 4:01 PM, Saúl Ibarra Corretgé wrote:
> Hi,
> 
> Here is my review of the -chat document.
> 
> - 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?

> - 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.

> - 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.)

> - Should we add text to map MSRP reports to XMPP receipts (XEP-0184)?
> They do map very well semantically. Now, XEP-0184 says that the ack
> may not be sent if "The recipient simply does not wish to return a
> receipt for the content message.", which pretty much renders it
> useless. Anyway, I think we do need some text explaining how MSRP
> success and failure ports should be dealt with.

I wonder if this belongs in the stox-chat spec or in an extension document.

(And BTW XMPP message receipts can be used outside of chat sessions, so
I think it applies more broadly than the stox-chat spec.)

> - In general: we don't have any example using CPIM, not sure if we
> should say anything about it.

What do you have in mind for CPIM examples? Do you mean examples other
than MSRP, or examples with CPIM payloads?

Peter

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