Re: [Stox] Review on -presence

Peter Saint-Andre <stpeter@stpeter.im> Thu, 01 August 2013 06:38 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 854EC21F9D2A for <stox@ietfa.amsl.com>; Wed, 31 Jul 2013 23:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.071
X-Spam-Level:
X-Spam-Status: No, score=-101.071 tagged_above=-999 required=5 tests=[AWL=-1.311, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_22=0.6, 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 bnwti0pkFYWA for <stox@ietfa.amsl.com>; Wed, 31 Jul 2013 23:38:45 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5304021F89A6 for <stox@ietf.org>; Wed, 31 Jul 2013 23:38:45 -0700 (PDT)
Received: from dhcp-6327.meeting.ietf.org (unknown [130.129.99.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 65EDFE831E; Thu, 1 Aug 2013 00:41:01 -0600 (MDT)
Message-ID: <51F99063.30203@stpeter.im>
Date: Thu, 01 Aug 2013 00:32:03 +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: =?windows-1252?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
References: <0CB65FBA-7262-4189-8852-5FC08A34D50D@ag-projects.com>
In-Reply-To: <0CB65FBA-7262-4189-8852-5FC08A34D50D@ag-projects.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Cc: "stox@ietf.org" <stox@ietf.org>
Subject: Re: [Stox] Review on -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, 01 Aug 2013 06:38:50 -0000

On 7/30/13 5:33 PM, Saúl Ibarra Corretgé wrote:
> Hi,
> 
> Here is my review of the -presence document:
> 
> - Sec 3.3.2 suggests that if the subscription is maintained but we
> have no presence state, a PIDF would be generated with a basic status
> of closed, but what would be the tuple ID, if we don't know any
> resource for this user anymore? We could also send an empty NOTIFY,
> which would achieve the same goal.

The empty NOTIFY sounds more consistent with the spirit of SIP presence.

> - Sec 3.3.2 specifies how to handle the case when a gateway
> translated a SIP subscription into an XMPP subscription and then the
> SIP side decided to end it, but doesn't mention what to do in case
> the XMPP side decides to end it. It should send a NOTIFY with
> Subscription-State: terminated;reason=rejected.

Agreed.

> - Sec 4.1, "Instant Message URI of the form <pres:user@domain>" -
> shouldn't this be "Presence URI of the form…" ?

Looks like a copy-and-paste error.

> - Using ID-123kdklejd doesn't seem to work as a valid xs:ID, TID-1234
> does work though, so we could use TID- as the prefix for tuple
> identifiers in examples and such.

I will double-check that against the XML specification.

> - Table 6 suggests that the Call-ID header should be matched to the
> presence stanza id, but the called won't change throughout the whole
> dialog, so we should use something else, which changes for each SIP
> transaction, what about the Via branch? Table 7 uses CSeq, FWIW.

You're right -- Call-ID is not right here. CSeq is better, and I think
we changed it in Table 7 but not Table 6.

> - Table 6 suggests that priority is translated as the PIDF priority
> for a tuple, but that's an attribute of the contact element, which we
> don't mention, but I guess we should. 

Good catch -- we don't seem to include the contact element in any of the
examples. Will fix.

> Also, the priority in PIDF is a
> float between 0 and 1, is it the same for XMPP?

Hmm. We had text about that in RFC 3922, and I suggest we copy that to
this draft (adjusting as necessary)...

   An XMPP presence stanza MAY contain a <priority/> child element whose
   value is an integer between -128 and +127.  The value of this element
   MAY be mapped to the 'priority' attribute of the <contact/> child of
   the PIDF <tuple/> element.  If the value of the XMPP <priority/>
   element is negative, an XMPP-CPIM gateway MUST NOT map the value. The
   range of allowable values for the PIDF 'priority' attribute is any
   decimal number from zero to one inclusive, with a maximum of three
   decimal places.  If an XMPP-CPIM gateway maps these values, it SHOULD
   treat XMPP <priority>0</priority> as PIDF priority='0' and XMPP
   <priority>127</priority> as PIDF priority='1', mapping intermediate
   values appropriately so that they are unique (e.g., XMPP priority 1
   to PIDF priority 0.007, XMPP priority 2 to PIDF priority 0.015, and
   so on up through mapping XMPP priority 126 to PIDF priority 0.992;
   note that this is an example only, and that the exact mapping shall
   be determined by the XMPP-CPIM gateway).

That's twice in one day I have looked at RFC 3922. ;-)

> - Sec 4.3, the translated XMPP stanza contains the full JID of
> Juliet, but where did we get the resource from? Shouldn't it go to
> the bare JID?

Another copy-and-paste error, I think.

Peter

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