Re: [sipcore] draft-barnes-sipcore-rfc4244bis

"Worley, Dale R (Dale)" <> Mon, 11 July 2011 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3D5121F8E63 for <>; Mon, 11 Jul 2011 11:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.25
X-Spam-Status: No, score=-103.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I5lYpvy8EOD0 for <>; Mon, 11 Jul 2011 11:55:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0078721F8DB5 for <>; Mon, 11 Jul 2011 11:55:48 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgABAA1GG06HCzI1/2dsb2JhbABTl2WPN3etKwKbOYVbXwSXb4tI
X-IronPort-AV: E=Sophos;i="4.65,516,1304308800"; d="scan'208";a="255998782"
Received: from unknown (HELO ([]) by with ESMTP; 11 Jul 2011 14:55:46 -0400
Received: from unknown (HELO ([]) by with ESMTP; 11 Jul 2011 14:48:47 -0400
Received: from ([]) by ([]) with mapi; Mon, 11 Jul 2011 14:55:45 -0400
From: "Worley, Dale R (Dale)" <>
To: Shida Schubert <>
Date: Mon, 11 Jul 2011 14:55:45 -0400
Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis
Thread-Index: Acw+0DQSy4Ac8gpxR3CVAB27tHKBTQBKxgga
Message-ID: <>
References: <>, <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: " WG" <>
Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Jul 2011 18:55:50 -0000

(replying to the message below)

Cullen was raising the question "Exactly how do you use History-Info to make the decisions that we think it will allow to be made?"  My concept is that we should present algorithms that (allegedly) process History-Info to make the decisions needed by the various use cases.  My message "[sipcore] 4244bis Application processing" ( was an attempt to present such algorithms -- note that those algorithms work in a different way than do the algorithms in 4244bis.  In principle, you can read the algorithms and tell whether or not History-Info (as we have defined it), processed by the presented algorithm, does what the use case needs.  If it *does*, then we know that History-Info captures enough information for the use case.

From: Shida Schubert []
Sent: Sunday, July 10, 2011 3:08 AM
To: Worley, Dale R (Dale)
Cc: Cullen Jennings; WG
Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis

Hi Dale;

 Could you elaborate as to what you are suggesting?


On Jun 23, 2011, at 4:50 AM, Worley, Dale R (Dale) wrote:

> ________________________________________
> From: [] On Behalf Of Cullen Jennings []
>> However, I would like to see some text added to section 8 that allowed implementers to use this specification to implemented some of the use cases it is designed to meet. Specifically I would like to see normative language on how a voicemail system can use the tags found in an incoming invite to determined which mailbox the call should be delivered too.
> _______________________________________________
> Most importantly, presenting algorithms for the use cases allows the reader to verify that the mechanism does accomplish what it was designed to do, and that there are not peculiar cases where the mechanism fails.
> Dale
> _______________________________________________
> sipcore mailing list