Subject: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt

From: "Elwell, John" <[email-masked]>
Date: Tue, 19 Jun 2007 21:03:35 +0100

Comments are solicited on this draft, which is a first step at trying to
pull together some of the discussions relating to DND during the last
year. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 19 June 2007 20:50
> To: [email-masked]
> Subject: I-D ACTION:draft-elwell-bliss-dnd-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: An Analysis of Do Not Disturb (DND) 
> Implementations in the Session Initiation Protocol (SIP)
> 	Author(s)	: J. Elwell, M. Vakil
> 	Filename	: draft-elwell-bliss-dnd-00.txt
> 	Pages		: 12
> 	Date		: 2007-6-19
> 	
>    Do Not Disturb (DND) is a commonly used expression for indicating a
>    condition where a human user of real-time communications does not
>    wish to be interrupted by incoming calls or other forms of
>    communication.  This document discusses the nature of DND, ways of
>    observing DND, and limitations of and possible improvements to DND
>    support in the Session Initiation Protocol (SIP) and the Rich
>    Presence Information Data Format (RPID).
> 
>    This work is being discussed on the [email-masked] mailing list.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-elwell-bliss-dnd-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in 
> the body of 
> the message. 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-elwell-bliss-dnd-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-elwell-bliss-dnd-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 19 Jun 2007 18:24:20 -0500

Hi John,

Good start, but I think there are things missing in there.

For example, there is the concept of a "Semi-permanent setting" (i.e.,
you change
your status to DND), and there is also dynamic "Do Not Disturb" that you
can do when
an incoming request.

I believe that the you are focussing strictly on the first one. But it
seems to me
that it should apply to both "DND" (static) and "Decline" (dynamic),
except for the
discussion of presence status.

I do think that a 480 or 486 are both valid and appropriate in most
cases (when you don't want
to affect the other branches).

As for the "what do we do with 6XX", my take is that we should do the
following:
- It should only be valid within the scope of the target domain.
- Proxies of the target domain should be able to interpret the 6XX
coming from a UAS as they
  see fit. For example, they may decide to treat a 603 as a 486 if they
have a policy to
  not allow global rejections. (there are many reasons to do so, not
just voicemail).

That leaves a good solution for manufacturers:
- An equipment vendor can have a "Busy Here" and "Busy Everywhere"
option, but the 
  network operator can avoid problems by treating them both as local if
there are
  compelling reasons to do it (e.g., forward to operator, voicemail,
pool, etc.). 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Tuesday, June 19, 2007 13:04
> To: [email-masked]
> Subject: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt
> 
> Comments are solicited on this draft, which is a first step 
> at trying to pull together some of the discussions relating 
> to DND during the last year. 
> 
> > logging in, type "cd internet-drafts" and then "get 
> > draft-elwell-bliss-dnd-00.txt".
> > 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Jun 2007 10:43:17 +0100

Francois,

Thanks for your comments. See below.

John 

> From: Francois Audet [mailto:[email-masked]] 
> Sent: 20 June 2007 00:24
> To: Elwell, John; [email-masked]
> Subject: RE: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt
> 
> Hi John,
> 
[JRE] You could indeed decide, on receipt of a call, to say you are in
DND for that call. I guess a simple "decline" perhaps needs to make a
distinction between "DND" (perhaps with a duration) and "I don't want to
talk to you at all", which is how 603 could be interpreted. I can add
some discussion of this for the next version.

> - It should only be valid within the scope of the target domain.
[JRE] You mean the domain of the UA that issues the 6xx? So if I send a
request to [email-masked] and that gets forwarded to
[email-masked], then if user2's UA issues a 6xx it should apply to
other destinations in example2.com but not to other destinations in
example1.com?
Also, would the 6xx then prevent the example2.com proxy from forwarding
to [email-masked]?

>   compelling reasons to do it (e.g., forward to operator, voicemail,
[JRE] I am not sure whether the scope of 6xx is something to be solved
just for DND or more generally. In the latter case it may not fit in
this draft.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jun 2007 10:14:29 -0400

I agree that this is a good start at addressing the problem.

Something you allude to in the requirements, but don't discuss much is 
this issue of policy control between the UAS and a proxy in the domain 
of its AOR that may be acting for it. In particular, you are suggesting 
that the UAS is providing data for the proxy to use in carrying out 
policies for the user of the UAS. This could be a complex subject.

I think it is potentially distinct from communicating reasons from the 
UAS/Proxy back to the UAC. In particular, there should be no reason for 
the UAS to lie about it reason for rejection when talking to its own 
proxy, but good reasons to do so when formulating a response to the UAC.

I'm not convinced that we need to be more explicit in responses to the 
UAC - the existing set seem rich enough to me. The fact that these may 
be generated in multiple circumstances is a feature, not a limitation. 
(This is analogous to using sendonly/recvonly/inactive for hold rather 
than *explicitly* indicating hold.)

It may be worth considering if there are needs to communicate more 
nuances about policy preferences between the UAS and its own proxy.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 20 Jun 2007 11:28:55 -0500

That's kind of what I am thinking as well.

I don't beleive we need "more codepoints", but I think we may need to
say more about the policies.

Paul, on the "no reason for the UAS to lie about its reason
for rejection when talking to its own proxy", I don't think
that's the real issue. The issue is that the UAS may be using
a reason that goes against the policies of it's proxies.
(Misconfiguration, stupid end-user, stupid device manufacturer, 
etc.). Specically, it could be using  6XX reasons when its proxy
has a policy to always provide some alternative treatment (e.g.,
route to another agent, voicemail, etc).

In my mind, it would suffice to explain this in the document. 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Wednesday, June 20, 2007 07:14
> To: Audet, Francois (SC100:3055)
> Cc: Elwell, John; [email-masked]
> Subject: Re: [BLISS] RE: I-D ACTION:draft-elwell-bliss-dnd-00.txt
> 
> Something you allude to in the requirements, but don't 
> discuss much is this issue of policy control between the UAS 
> and a proxy in the domain of its AOR that may be acting for 
> it. In particular, you are suggesting that the UAS is 
> providing data for the proxy to use in carrying out policies 
> for the user of the UAS. This could be a complex subject.
> 
> I think it is potentially distinct from communicating reasons 
> from the UAS/Proxy back to the UAC. In particular, there 
> should be no reason for the UAS to lie about it reason for 
> rejection when talking to its own proxy, but good reasons to 
> do so when formulating a response to the UAC.
> 
> I'm not convinced that we need to be more explicit in 
> responses to the UAC - the existing set seem rich enough to 
> me. The fact that these may be generated in multiple 
> circumstances is a feature, not a limitation. 
> (This is analogous to using sendonly/recvonly/inactive for 
> hold rather than *explicitly* indicating hold.)
> 
> It may be worth considering if there are needs to communicate 
> more nuances about policy preferences between the UAS and its 
> own proxy.
> 
> 	Thanks,
> 	Paul
> 
> Francois Audet wrote:
> > Hi John,
> > 
> > you change your status to DND), and there is also dynamic "Do Not 
> > Disturb" that you can do when an incoming request.
> > 
> > seems to me that it should apply to both "DND" (static) and 
> "Decline" 
> > (dynamic), except for the discussion of presence status.
> > 
> > cases (when you don't want to affect the other branches).
> > 
> >   see fit. For example, they may decide to treat a 603 as a 486 if 
> > they have a policy to
> >   network operator can avoid problems by treating them both 
> as local 
> > if there are
> >> Comments are solicited on this draft, which is a first 
> step at trying 
> >> to pull together some of the discussions relating to DND 
> during the 
> >> last year.
> >>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 20 Jun 2007 11:42:14 -0500

> Sent: Wednesday, June 20, 2007 02:43
> To: Audet, Francois (SC100:3055); [email-masked]
> [JRE] You mean the domain of the UA that issues the 6xx? So 
> if I send a request to [email-masked] and that gets 
> forwarded to [email-masked], then if user2's UA issues a 
> 6xx it should apply to other destinations in example2.com but 
> not to other destinations in example1.com?

Correct.

> Also, would the 6xx then prevent the example2.com proxy from 
> forwarding to [email-masked]?

I think this depends on it's local policy as per my other email.

> [JRE] I am not sure whether the scope of 6xx is something to 
> be solved just for DND or more generally. In the latter case 
> it may not fit in this draft.

For now, I suggest we document it in your draft and see what the group
wants to do with it. You could flag it as OPEN ISSUE. It may be as
simple as a clarification or errata to 3261, or it may be something
bigger.