Subject: RE: [SIP] Re: Comments on draft-ietf-sip-cc-transfer-04 (out-of-b and subs)

From: Robert Sparks <[email-masked]>
Date: Fri, 25 May 2001 09:55:35 -0400

There was quite a bit of discussion on this topic on the
list and at the meetings. In summary, the implicit subscribe
model was chosen at the SHOULD strength instead of MUST for
the very reasons you listed.

If you have an app where you have a very good reason to
not send the NOTIFY and you've done the work to ensure you're
not breaking any features that rely on it by accident, you aren't
required to send it.

RjS

> -----Original Message-----
> From: Petri K. Koskelainen [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 11:02 AM
> To: [email-masked]
> Subject: [SIP] Re: Comments on draft-ietf-sip-cc-transfer-04
> (out-of-band subs)
> 
> 
> Hi,
> 
> A comment about draft-ietf-sip-cc-transfer-04:
> 
> In page 8:
>    ", the UA receiving the REFER SHOULD notify the agent sending 
>    the refer using the NOTIFY mechanism.." 
> 
> I can imagine many situations (also outside of CC draft) in 
> which the client
> in some cases wants to be notified and in some cases does not 
> want to be 
> notified.
> 
> Is there any way to define this optionality in REFER ?
> (other than new header)
> 
> I was thinking about caller prefs mechanism but it does not 
> seem to allow
> that possibility either.
> 
> I'd prefer that UAC sending REFER (or other non-SUBSCRIBE) 
> method does 
> not have to be automatically prepared to receive NOTIFYs (of 
> course there 
> is same Call-ID required but it is still inconvenient in some cases). 
> Instead, the willingness to receive NOTIFY would be defined in
> the non-SUBSCRIBE method itself (like in REFER).
>  
> Also, minor issue is that this is 
> yet-another-extra-SIP-request/response 
> which should be avoided in certain environments (e.g. 
> wireless user in 
> some cases may want to avoid unnecessary notifications).
> 
> 
> This seems to be more general SIP issue, not limited to CC draft..
> 
>  
> --
> Petri
> 
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> [email-masked] with "subscribe" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Petri K. Koskelainen" <[email-masked]>
Date: Fri, 25 May 2001 10:52:29 -0400 (EDT)

Hi,

It is still a MUST requirement for the client: (in page 8)

  "..the agent that issued the REFER MUST be prepared to receive a NOTIFY.."

There is no way to prevent NOTIFYs (in the case client does not want it).
Client may just hope that application does not send it.

This isn't major problem, but it would be nice to let the originating 
UAC (rather than the server processing REFER) to decide whether NOTIFY
is needed.

For example, new header for non-SUBSCRIBE methods like notify: yes|no.

--
Petri