Re: [Stox] Brian Haberman's No Objection on draft-ietf-stox-chat-10: (with COMMENT)

Peter Saint-Andre - &yet <> Wed, 04 March 2015 23:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7E4A61A009B for <>; Wed, 4 Mar 2015 15:40:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U6MXxsiw-fUU for <>; Wed, 4 Mar 2015 15:40:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A821F1A0076 for <>; Wed, 4 Mar 2015 15:40:40 -0800 (PST)
Received: by iecrp18 with SMTP id rp18so4055614iec.10 for <>; Wed, 04 Mar 2015 15:40:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=z4Zl6vgkYekxHmCZPHMdvws3Vd28i9cmE82IlT0+IFM=; b=EgvVn1ajvwrjoFJzPWymwmGRv8vIevua5XYEVB/XfkDOF3sTuCiqSRjJqdK651nueI 2ancKuFl9Y3CXCiA7Gi0LXTyLBjMeXZF+9FPHPeviuLcCVccvpa98G0eoWIg+eKSjTTS VeUCgFn9rfi8cO2fJyxk0hzU1gdgZ7qWQh9f2t1fKPJVvMak6olHJ0EHcMNJtJ3NPGo6 WYwjvLDok0lOuO1cC1jzFkFiKPKgpGvKMOZ8SL1LzDBBshqd3PA5ATNQmdaS/SkswpfG VXUQ6mxXGddzCWNkQcHAllmhR3YCJnJBTssSZLYNvIeAV7QZODBJp3hQAtjsro8X750Y Babg==
X-Gm-Message-State: ALoCoQl4c2+wj1YFqG/jkVyAsPVhUMKmWLjabyJPgbmoQJyfHiGbmKgO/waP/JkoR4mwG14xPFga
X-Received: by with SMTP id ih19mr15984132igb.47.1425512440085; Wed, 04 Mar 2015 15:40:40 -0800 (PST)
Received: from aither.local ( []) by with ESMTPSA id c8sm3847721igx.9.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 15:40:39 -0800 (PST)
Message-ID: <>
Date: Wed, 04 Mar 2015 16:40:38 -0700
From: Peter Saint-Andre - &yet <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Brian Haberman <>, The IESG <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Stox] Brian Haberman's No Objection on draft-ietf-stox-chat-10: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Mar 2015 23:40:43 -0000

On 3/3/15 8:16 AM, Brian Haberman wrote:
> Brian Haberman has entered the following ballot position for
> draft-ietf-stox-chat-10: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> No objection to the publication of this document, but I do have a
> question for you to consider...
> Sections 4 and 6 talk about implementing timers to deal with the lack of
> a GONE message in XMPP.  Any thoughts on having this document suggest
> possible values for such timers?  Not sure if that makes sense for
> protocols much closer to real users, but thought I would ask.

The problem is that implementers never agree on the timer values. For 
example (in a slightly different context), RFC 4975 notes the following 
for MSRP-related timers:

    If success reports are requested, i.e., the value of the Success-
    Report header field is "yes", the sending device MAY wish to run a
    timer of some value that makes sense for its application and take
    action if a success report is not received in this time.  There is no
    universal value for this timer.  For many IM applications, it may be
    2 minutes while for some trading systems it may be under a second.
    Regardless of whether such a timer is used, if the success report has
    not been received by the time the session is ended, the device SHOULD
    inform the user.

In the XMPP community we had quite a bit of discussion about this at one 
point and couldn't come to agreement. That's why XEP-0085 (Chat State 
Notifications) states the following about the <gone/> state:

    User has not interacted with the chat session interface, system,
    or device for a relatively long period of time (e.g., 10 minutes).

The relevant contrast here is with the <inactive/> state:

    User has not interacted with the chat session interface for an
    intermediate period of time (e.g., 2 minutes).

There's quite a bit of fudging there, but pointing to the specifics of 
XEP-0085 might be helpful to some implementers.


Peter Saint-Andre