[sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: 200 response

Brett Tate <brett@broadsoft.com> Thu, 13 November 2014 17:31 UTC

Return-Path: <brett@broadsoft.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E9A1A8BAF for <sipcore@ietfa.amsl.com>; Thu, 13 Nov 2014 09:31:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak18ZdkgcgFn for <sipcore@ietfa.amsl.com>; Thu, 13 Nov 2014 09:31:58 -0800 (PST)
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F48B1A8AE9 for <sipcore@ietf.org>; Thu, 13 Nov 2014 09:31:56 -0800 (PST)
Received: by mail-qg0-f49.google.com with SMTP id z60so10820488qgd.36 for <sipcore@ietf.org>; Thu, 13 Nov 2014 09:31:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=Ko6fCNXDPyTC38Ke0DFoN0v8wxfVCbTFtF76E+3ygHg=; b=SbE2qy4gtQYvbGsqIvbLZatB6/I+SFzJvUbT5+UHWKNo+oahzblJ2PBuZVUyPMBn4W hGZzCtL6KTTgSEwdIHxE7gDHwvIIJYNwXCkOphEI9gSEY8Qnuthub6eZqz5Oc7DX9Mqe 5ZCMTYHwDuGuGNzUwRkcr5lTitZHr/6oieFhwRlC1bpcHXqbXOh0PtfiOJyAjz5EN+GQ xcApttht6aLa1cfSGwgzETiyj1bzqMNgRZFRCbJpa0ZHP5sWhgsiXk9QTswSP1M4UdO7 bfXwL9bderAjxdRu1oFSHsCHhsQg0N+s9Xr0eCVEeu7RusQ19vlSFoTY5FTXU3hH5M8m lffQ==
X-Gm-Message-State: ALoCoQlXIjrShv3PFHVld9Qd9jzHUm7Y4zan3BtbHAp9+//l71r8WbfbS7XrqPzykpbr+QMd91N6
X-Received: by 10.229.115.7 with SMTP id g7mr4733064qcq.2.1415899915125; Thu, 13 Nov 2014 09:31:55 -0800 (PST)
From: Brett Tate <brett@broadsoft.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac//Z6O7nJc9xfGTR9uU8Bj8zlFlcA==
Date: Thu, 13 Nov 2014 12:31:51 -0500
Message-ID: <b418c64bf7c65fbf17091db71b8f4675@mail.gmail.com>
To: draft-sparks-sipcore-refer-explicit-subscription@tools.ietf.org, sipcore@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/RXMuyFd_Vf8478CtDgLVVcF-Hv8
Subject: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: 200 response
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Nov 2014 17:32:00 -0000

Hi,

I just wanted to relay a comment that Dale made on the sip-implementors
list concerning draft-sparks-sipcore-refer-explicit-subscription-02
section 4.8.

The draft currently restricts the Refer-Events-At to have meaning only
within 200 response instead of 2xx responses.

One of the benefits of loosening up the restriction is that the RFC will
not need to be updated if new 2xx response codes are defined.

Thanks,
Brett

-----

> From: Brett Tate <brett@broadsoft.com>

> Draft-sparks-sipcore-refer-explicit-subscription intends to deprecate
> the use of 202 for a REFER response (i.e. updating RFC 3515).

Specifically, 202 is deprecated in favor of 200.

> If you think (or know) it will cause interoperability issues, please
> express your concerns and/or update code as needed.

I see in section 3.8 of
draft-sparks-sipcore-refer-explicit-subscription-02:

   The 'Refer-Events-At' header field is only meaningful in a 200
   response to a REFER request.  If it appears in the header of any
   other SIP message, its meaning is undefined and it MUST be ignored.

It seems to me that this is dangerously strict, and should say "is only
meaningful in a *2xx* response to a REFER request".

Dale