Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?

Adam Roach <> Fri, 12 November 2010 02:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B9343A6781 for <>; Thu, 11 Nov 2010 18:53:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.56
X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NmRVYQl-GB98 for <>; Thu, 11 Nov 2010 18:53:10 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id 83DF43A68B6 for <>; Thu, 11 Nov 2010 18:53:10 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id oAC2raF0011411 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 11 Nov 2010 20:53:39 -0600 (CST) (envelope-from
Message-ID: <>
Date: Fri, 12 Nov 2010 10:53:35 +0800
From: Adam Roach <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Hadriel Kaplan <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc: " WG" <>
Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Nov 2010 02:53:12 -0000

[as chair]

On 11/12/10 10:06 AM, Hadriel Kaplan wrote:
> When I read Marianne's draft, it sounds like the use-case she's trying to cover is call-forwarding, for things like voicemail systems to be able to detect/process.  So what really confuses me is I thought one of the basic applications 4244bis was trying to enable was exactly that one.  Right?  If it's not sufficient to achieve that, I think we've screwed up somewhere... or at least need to make sure it's not something we can fix in 4244bis, because now would be a really good time to fix it.  :)

At IETF 75, when we were discussing the applicability of 4244bis to the 
SIPCORE charter (as opposed to simply developing a new document that was 
limited to describing how to use 4244 to deliver URI parameters), one of 
the rather important points that was made was that we would "limit bis 
changes to [those necessary to] satisfy target uri requirements."

If the RAI community at large wants to expand this to include a general 
tune-up and/or kitchen-sinking of 4244, then we need to figure out a way 
to put the SIPCORE milestone to rest and then send the rest of the 
changes to DISPATCH. I have no interest in letting this milestone drag 
on as people come up with new things they'd like to see added or changed.