[sipcore] 4244bis issue summary/proposed changes

Mary Barnes <mary.ietf.barnes@gmail.com> Fri, 07 May 2010 20:22 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9C863A684A for <sipcore@core3.amsl.com>; Fri, 7 May 2010 13:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.538
X-Spam-Level:
X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id savw-oDHzqg1 for <sipcore@core3.amsl.com>; Fri, 7 May 2010 13:22:18 -0700 (PDT)
Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.210.179]) by core3.amsl.com (Postfix) with ESMTP id 9CA283A69A0 for <sipcore@ietf.org>; Fri, 7 May 2010 13:22:14 -0700 (PDT)
Received: by yxe9 with SMTP id 9so1160030yxe.29 for <sipcore@ietf.org>; Fri, 07 May 2010 13:21:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=ERaKcH99zZeZGyqFJbiz/dTeYmDv1l3f8ik0spcDnns=; b=N2/GVY6f/+g8uiztlCFjvBuJ2zpg9CkzJQwizi0exvNGzfJ3BF4HvxcsoZwWArvO7/ Vz4sdWffdIomc9wsZh6Iovt+fKO8oNdw60T/Iptre32u5jHAtk9r2HUWR5hBHUuee0fz WiBUlw9QtwpMgKojL63FccjmenJ4GYGFJrWp4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=kj7YYczUtng9s07BRRj4Ey8wjciQm0ycbtzy1OBCE/fA5ibK4qQA9TV8tr8wJELiBb I17iAdKj2ZM2FBPK434PMFS0jQUH353xhWpNeY9G+wOQum31Ja/J6N5mus+uysqzO0hx yd4FCu8zrx7V89Jfu0BFUeefGT5rFKltmXN/A=
MIME-Version: 1.0
Received: by 10.231.182.140 with SMTP id cc12mr346852ibb.18.1273263718344; Fri, 07 May 2010 13:21:58 -0700 (PDT)
Received: by 10.231.147.148 with HTTP; Fri, 7 May 2010 13:21:58 -0700 (PDT)
Date: Fri, 07 May 2010 15:21:58 -0500
Message-ID: <r2j184b5e71005071321r78083818s70974f46d0ee7854@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: SIPCORE <sipcore@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Francois AUDET <francois.audet@skype.net>, Shida Schubert <shida@agnada.com>
Subject: [sipcore] 4244bis issue summary/proposed changes
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 07 May 2010 20:22:22 -0000

Hi all,

This is a follow-up to the discussion we had on 4244bis in Anaheim and
some subsequent discussion on the mailing list.  The primary point of
contention was around the support for voicemail.  The example we have
in the WG -00  describes the handling as based on policy and provides
two examples of such.  However, that's really not the best approach
and indeed voicemail really has two basic use cases that are specific
to configuration and thus a UAS for a specific configuration does have
determinant behavior and we can specify the exact mechanism by which
the appropriate information is derived from the History-Info header.

Our proposal is actually to move the majority of the use cases out of
this document into a separate informational (or BCP) document and add
more illustrative text and precise descriptions as to how the
necessary information  is derived from the History-Info header.  We
will add general text to 4244bis describing basic rules for using the
information in the UAS and application considerations sections.   We
will keep the basic examples from RFC 4244. In one sense, we are
reverting to what we had in earlier versions, except that the call
flows will be kept in sync with 4244bis.  We can decide where the call
flows should live once we get the updated documents submitted.

For background, here's a link to the earlier thread:
http://www.ietf.org/mail-archive/web/sipcore/current/msg02180.html

and meeting minutes:
http://www.ietf.org/proceedings/10mar/minutes/sipcore.html

We'll try to get the updates done within the next couple weeks.

Thanks,
Mary.