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

Philipp Hancke <fippo@goodadvice.pages.de> Thu, 19 September 2013 17:13 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 B78E021F9433 for <stox@ietfa.amsl.com>; Thu, 19 Sep 2013 10:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.164
X-Spam-Level:
X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, 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 fWjC3838Neq0 for <stox@ietfa.amsl.com>; Thu, 19 Sep 2013 10:13:41 -0700 (PDT)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 5727B21F94FF for <stox@ietf.org>; Thu, 19 Sep 2013 10:13:38 -0700 (PDT)
Received: from [192.168.2.100] (p54970393.dip0.t-ipconnect.de [84.151.3.147]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8JHDZPi013046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <stox@ietf.org>; Thu, 19 Sep 2013 19:13:36 +0200
Message-ID: <523B30B9.4030509@goodadvice.pages.de>
Date: Thu, 19 Sep 2013 19:13:29 +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> <523A7520.70002@stpeter.im> <523B2A83.7080302@stpeter.im>
In-Reply-To: <523B2A83.7080302@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: Thu, 19 Sep 2013 17:13:46 -0000

Am 19.09.2013 18:46, schrieb Peter Saint-Andre:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Philipp, thanks for the review. Comments inline.

Stuff that is done removed. Thanks for addressing the issues.

[...]
>>> chat: example f2: call-id: contain jid? how about uniqueness?.
>
> Yes, RFC 3261 says they need to be unique:
>
>     In a new request created by a UAC outside of any dialog, the Call-ID
>     header field MUST be selected by the UAC as a globally unique
>     identifier over space and time unless overridden by method-specific
>     behavior.  All SIP UAs must have a means to guarantee that the Call-
>     ID header fields they produce will not be inadvertently generated by
>     any other UA.
>
> I was unthinkingly following the examples in specs like RFC 4975. I'll
> change them to be UUIDs.

I think what I mean was "the call id should be something along the lines 
of 711609sa.juliet.example.com". The intent was the same however.

[...]
>>> before example F4: the gateway acknowledges on behalf of juliet?
>
> Yours was a very brief comment and I'm not sure I understand the force
> of your question. Are you wondering why there's an ACK at this point
> in the negotiation? That's what I see in RFC 4975:

What I meant (and i needed to parse this again, too) was that I think 
the gateway acknowledges on behalf of Juliet, not Romeo as the text 
says. The example itself is ok.

philipp