Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-03.txt

Henning Schulzrinne <hgs@cs.columbia.edu> Mon, 17 February 2003 18:51 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28239 for <ieprep-archive@odin.ietf.org>; Mon, 17 Feb 2003 13:51:12 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1HIuQ714223 for ieprep-archive@odin.ietf.org; Mon, 17 Feb 2003 13:56:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HIuPp14220 for <ieprep-web-archive@optimus.ietf.org>; Mon, 17 Feb 2003 13:56:25 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28212 for <ieprep-web-archive@ietf.org>; Mon, 17 Feb 2003 13:50:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HIt4p14141; Mon, 17 Feb 2003 13:55:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1HIrBp14046 for <ieprep@optimus.ietf.org>; Mon, 17 Feb 2003 13:53:11 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28147 for <ieprep@ietf.org>; Mon, 17 Feb 2003 13:47:27 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1HIp1P5012766 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 17 Feb 2003 13:51:02 -0500 (EST)
Message-ID: <3E512F2F.7010302@cs.columbia.edu>
Date: Mon, 17 Feb 2003 13:51:27 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Gunn, Janet" <Janet.Gunn@DynCorp.com>
CC: 'Ken Carlberg' <K.Carlberg@cs.ucl.ac.uk>, ieprep@ietf.org
Subject: Re: [Ieprep] I-D ACTION:draft-ietf-ieprep-framework-03.txt
References: <CBED705A7FD2D311865500508B1089410A414B2C@chntex02.is.dyncorp.com>
In-Reply-To: <CBED705A7FD2D311865500508B1089410A414B2C@chntex02.is.dyncorp.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Indeed. The requirements draft takes great pains to be solution-neutral 
and thus does not address a specific mechanism. In reality, the number 
of possibilities aren't infinite, given the constraints of the protocol. 
There will shortly be a solution-oriented draft that does indeed propose 
a new header field, after trying to exhaustively go through all the 
design options and identifying why no other solution satisfies the 
requirements stated. As always, I might have missed possibilities or 
solutions, but I'm sure that participants in this and SIP-related 
working groups won't be shy in pointing out any such omission.

In short, Janet is correct.

Gunn, Janet wrote:
> Maybe Henning can clarify, but the current version of
> draft-ietf-ieprep-sip-reqs-03.txt says
> "This document describes requirements rather than possible existing or
>    new protocol features. Although it is scoped to deal with SIP-based
>    applications, this should not be taken to imply that mechanisms have
>    to be SIP protocol features such as header fields, methods or URI
>    parameters."
> 
> It presents requirements for which a new header field is the "obvious"
> solution, but no longer states it as a requirement FRO a header field.
> 
> -----Original Message-----
> From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk]
> 
> 
>>Pg 11 reference to Henning's document - it no longer refers explicitly
>>to headers.
> 
> 
> the original passage is:
> 
>    [15] is a (soon to be) RFC that defines the requirements for a new
>    header field for SIP in reference to resource priority.  This new
>    header field is meant to provide an additional measure of distinction
>    that can influence the behavior of gateways and SIP proxies.
> 
> my understanding is that it pertains to requirements for a header *field*.  
> so yes, we are in agreement.
> _______________________________________________
> Ieprep mailing list
> Ieprep@ietf.org
> https://www1.ietf.org/mailman/listinfo/ieprep

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep