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

Peter Saint-Andre <stpeter@stpeter.im> Mon, 23 September 2013 04:12 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 B94E811E80D2 for <stox@ietfa.amsl.com>; Sun, 22 Sep 2013 21:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.832
X-Spam-Level:
X-Spam-Status: No, score=-102.832 tagged_above=-999 required=5 tests=[AWL=0.897, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 C5iSev6Xms8L for <stox@ietfa.amsl.com>; Sun, 22 Sep 2013 21:12:32 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A1B9B11E8186 for <stox@ietf.org>; Sun, 22 Sep 2013 21:12:25 -0700 (PDT)
Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2A1E341639; Sun, 22 Sep 2013 22:17:26 -0600 (MDT)
Message-ID: <523FBFA2.3050902@stpeter.im>
Date: Sun, 22 Sep 2013 22:12:18 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Philipp Hancke <fippo@goodadvice.pages.de>
References: <5203E484.4050902@goodadvice.pages.de>
In-Reply-To: <5203E484.4050902@goodadvice.pages.de>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
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 04:12:36 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks again for the review. Comments inline.

On 8/8/13 12:33 PM, Philipp Hancke wrote:

> groupchat: 2: at least in RFC 6120, jid stands for jabber id, not
> jabber identifier.

Correct. Will fix.

> 3.1: Room Nickname -> lowercase?

Sure.

> 3.1: example f2: conversion->conversation?

More like conversion->mapping :-)

BTW in the -chat spec I numbered all the examples sequentially, and
I'll start doing that here too.

> table 1: thread<->call id

Yes.

> 3.2: example f7: possibly use by= on the error element?

Sure, by='verona@chat.example.org' seems good.

> xep 0045 has the conflicting resource in the from

Correct. Will fix.

> 3.4: "Occupant JID in another room" -- i don't think mediated 
> invites work across different rooms.

Section 7.8.2 of XEP-0045 states in part:

###

It may be wondered why the invitee does not send the decline message
directly to the inviter. The main reason is that certain
implementations might choose to base invitations on occupant JIDs
rather than bare JIDs (so that, for example, an occupant could invite
someone from one room to another without knowing that person's bare
JID). Thus the service needs to handle both the invites and declines.

###

However, I'm not sure how widely that feature is implemented.

> example f1: hecate is benvolio? c&p error from 0045

Will fix.

> example f2: contact juliet@juliet.example.com has a wrong host?

You are right.

> reeived -> received

Yes.

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

> below f4 there is a sip/2.0 200 ok on its own?

Will fix.

> 3.5: table 2: xmpp From/To -> from/to

Will fix.

> ex f9: where is juliets own presence in msrp?

Good catch. Will fix.

> ex f11: where is juliets own presence with code 110?

Will fix.

> ex f14: mapping <message id/> to Message-ID does msrp have a
> concept of room history?

I'm not sure.

> 3.6.2: do we have an equivalent disco feature for muc?

No, it's assumed by support for 'http://jabber.org/protocol/muc'.

> 3.7: does xmpp still support the <status/> when in muc? In IRC
> this has caused PART spam

Yes:

http://xmpp.org/extensions/xep-0045.html#changepres

> 4.1: ex f5: lack of error until when? must wait until receiving
> 110 status?

We might way "within a reasonable amount of time, such as 5 seconds".

> 4.4: presence broadcast before ack? must buffer until receiving
> 110 ack?

Your comment is a bit cryptic. Would you please expand it?

> 4.5.1: use message id instead of guessing?

Good idea.

Thanks for the feedback!

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/

iQIcBAEBAgAGBQJSP7+iAAoJEOoGpJErxa2p658P/Rau0avsqCSulg1MmKj2YBrQ
I6VCkLROogGZ7HU2UvARdey4btzmbmZt4QJgJeCf31DV08KqkXnEdiGuJi1i/4AA
lcKiCmPR4F5XOEOee50z0p3Ol/jRSBACljVClKTHlyr6k0aT8ZO3AufhxZSVPfLb
QfxG08uudwXzgNoodup1cJnPfCLj32cGop8WqexWEeLmCEYQYGdkrPAEBz57AC56
KsCP9AIfs/Y6KLJ/LF0ap49fuv6klWQ9QOBocQDU8fd8MpzZkeHn+nR8g+EpfA9W
KFAYJ+HI9/ZQ2BhAFm7xHf8K3Iez9W4FkSTyO11w3M30vyChS32U/l5YBOcXxwRM
ejwLfpNaD2aLoMYZgHWR5fgOox7r24sRu+/74eHzeuH83lkkE+CVzYy272HFxRWY
qufE5m/4Tss02WpY5Aw1DSqIruEVZ6Z1IQF0Oy4iBLFxyKO7XTiG38xy8PaDL3J7
6O1vcDC2fHMPQ6b+45R2mhssevpLOPDEIDbgd3Feql4LzSjsrCQaKa12gp6jvFmm
DMguJGHYXq6wvM2fN3GH4y/T5v0DKbH/y2VZq+ZIn9t8QxoJbo8ysFCpu6yvH5r9
zg5qvmB6n5rMEe+KxCx8WxmUDDwAB9wjKAy3Qm9topD5nSnjd2K+OFwv/bvTfII/
Vmqa8IKbS0bNxgo14XIo
=XPXt
-----END PGP SIGNATURE-----