Re: [Stox] review of core, chat, groupchat and presence

Philipp Hancke <fippo@goodadvice.pages.de> Mon, 23 September 2013 05:58 UTC

Return-Path: <fippo@goodadvice.pages.de>
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 D698011E8195 for <stox@ietfa.amsl.com>; Sun, 22 Sep 2013 22:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.017
X-Spam-Level:
X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_20=-0.74, 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 deHHksXGHmVc for <stox@ietfa.amsl.com>; Sun, 22 Sep 2013 22:57:56 -0700 (PDT)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id C183911E8199 for <stox@ietf.org>; Sun, 22 Sep 2013 22:57:55 -0700 (PDT)
Received: from [192.168.2.100] (p54972204.dip0.t-ipconnect.de [84.151.34.4]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8N5vrLX005270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <stox@ietf.org>; Mon, 23 Sep 2013 07:57:54 +0200
Message-ID: <523FD85C.6010600@goodadvice.pages.de>
Date: Mon, 23 Sep 2013 07:57:48 +0200
From: Philipp Hancke <fippo@goodadvice.pages.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: stox@ietf.org
References: <5203E484.4050902@goodadvice.pages.de> <523FBFA2.3050902@stpeter.im>
In-Reply-To: <523FBFA2.3050902@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Stox] review of core, chat, groupchat and presence
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: Mon, 23 Sep 2013 05:58:02 -0000

 > Thanks again for the review. Comments inline.

As before, removing items done.

new nit: [length] looks like it should be replaced with the examples 
actual length in three places. Only seen in -groupchat.

[...]
>> example f3 is not shown
>
> I don't feel that we need to show every 200 OK. Yes, we put the
> example in example.com, but sometimes you really can have too many
> examples. :-)

Right. But then it might make sense to either add a "not shown" marker 
in the ascii art or not number them. I'll check if that happens often 
enough to make sense.

[...]
>> 4.4: presence broadcast before ack? must buffer until receiving
>> 110 ack?
>
> Your comment is a bit cryptic. Would you please expand it?

Hah, that was the only comment you found cryptic? :-)

btw: it might make sense to reuse the caption from XEP-0045 (7.2.3 
Presence Broadcast) for the caption of F7 (which is raw, unbridled xmpp 
and not translated; current text seems copy-paste from F11 in sect 3.5):
  "Service Sends Presence from Existing Occupants to New Occupant"

Now the attempt to decipher my comments:
First part:
In MUC, the participant lists is sent to the new occupant (muc example 
21) before the new occupants own presence (muc  example 24) and 
therefore potentially before any acknowledgements that might be required 
on the MSRP side. Is that a problem?


Second part:
In example F10, two (or more) stanzas are translated into a single 
event. Unless you can do partial updates (Emil? I think you mentioned 
such a thing for COIN) here, the gateway needs to know when it can 
dispatch example 4.4 -- upon receiving the participants own presence, 
which might come with a 110 status code. Since I don't think all xmpp 
serveers do 110, i think there is some text required that the gateway 
needs to be able to recognize the self-presence and not mistake it as 
part of the participants list.
(should it be participant_s_ presence in the caption?)

Is that clearer?