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

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Thu, 7 Apr 2005 12:03:10 -0500

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP