[Sipping] RE: Comment on RE: WGLC draft-ietf-sipping-callerprefs-usecases-03.txt

"Dolly, Martin C, ALABS" <mdolly@att.com> Thu, 07 April 2005 17:03 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14804 for <sipping-web-archive@ietf.org>; Thu, 7 Apr 2005 13:03:38 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaYU-0002ct-QF for sipping-web-archive@ietf.org; Thu, 07 Apr 2005 13:12:35 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaPk-0005b6-RZ; Thu, 07 Apr 2005 13:03:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaPg-0005Yk-WA for sipping@megatron.ietf.org; Thu, 07 Apr 2005 13:03:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14771 for <sipping@ietf.org>; Thu, 7 Apr 2005 13:03:25 -0400 (EDT)
Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaYF-0002Yt-BA for sipping@ietf.org; Thu, 07 Apr 2005 13:12:21 -0400
Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j37H0bqv021595 for <sipping@ietf.org>; Thu, 7 Apr 2005 12:03:16 -0500
Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh5i.attrh.att.com (7.2.052) id 423DAD7E003D22CE; Thu, 7 Apr 2005 13:03:10 -0400
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Thu, 07 Apr 2005 12:03:10 -0500
Message-ID: <28F05913385EAC43AF019413F674A0170A412D69@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: Comment on RE: WGLC draft-ietf-sipping-callerprefs-usecases-03.txt
Thread-Index: AcU7enig6XtcUkPkSnqPrUQ/swOcAAAGHXGw
From: "Dolly, Martin C, ALABS" <mdolly@att.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: quoted-printable
Cc: Rohan Mahy <rohan@ekabal.com>, Dean Willis <dean.willis@softarmor.com>, leo@cisco.com, sipping <sipping@ietf.org>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: [Sipping] RE: Comment on RE: WGLC draft-ietf-sipping-callerprefs-usecases-03.txt
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: quoted-printable

Paul,

See inline, Cheers, Martin

Paul K wrote, April 07, 2005:
> Hello,
> 
> The use cases are well written and very clear.
> 
> It would be useful to identify dependencies in the introduction or a
background section, particularly to: 
> (1) RFC 3840, Indicating User Agent Capabilities in SIP, for the new
media tags, expressing capabilities in a Registration, usage of the
content negotiation framework, etc..

The reference is already there in the Introduction. What more are you 
asking for?
>>>mcd - I feel that the reader needs to read RFC 3840/41 prior to
reading the use cases. So that in addition to the references that are
already there, if there was some text that expanded on why they should
read RFC 3840/41, I think would benefit the reader.
>>>end


> Lastly, the draft, along with RFC 3840/3841, describe the behavior
starting at the SIP UA. And though this may be out of scope, I feel
there should be something on how the user (a person) conveys their
preference(s) to the SIP UA via ???. The answer maybe that this is an
implementation issue.

This is a hard one. My personal opinion is that I don't expect a UA to 
provide a *general* mechanism for a user to express callerprefs for a 
call. Instead, I expect that the use of callerprefs will be implicit in 
the implementation of more coarse grained features. Exactly how that 
happens is TBD. (Example 3.19 does provide one example.)

I look on this as an introduction *to developers* of a mechanism that is

powerful but obscure. It shows the kinds of things that are (and are 
not) possible with this mechanism. I expect actual applications to come 
later. I guess a few words can be added explaining that.
>>>mcd - thanks
>>>end

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP