Subject: RE: [Sip] Issue with draft-ietf-sip-refer-with-norefersub-03

From: "Orit Levin" <[email-masked]>
Date: Tue, 25 Oct 2005 16:26:15 -0700

Andrew,
I agree with your point and suggest to fix this statement in the 48
editor's hours, unless the chairs think differently.
 
Orit.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andrew Allen
	Sent: Monday, October 24, 2005 11:09 PM
	To: [email-masked]
	Subject: [Sip] Issue with
draft-ietf-sip-refer-with-norefersub-03

	Orit

	Orit I have an issue with the last paragraph in section 4 of the
current draft.

	   The "norefersub" tag, when included in the Require header
field

	   (always in conjunction with the "Refer-Sub" header field set
to

	   "false"), specifies that the REFER-Recipient MUST process a
REFER

	   transaction without establishing an implicit subscription.
In this

	   case, if the REFER-Recipient either doesn't support the
extension or

	   is not willing to grant the request, the REFER request MUST
be

	   rejected by sending "420 Bad Extension" response back to the
REFER-

	   Issuer.

	I have not been following discussions on the draft closely but I
assume that the reason why the Refer-sub header was added to the draft
was because the semantics for the use of Require header are not to
require a particular behavior other than to require that the UAS support
the extension(s) identified by the option tags in order to accept the
request containing the Require header.  The above text from section 4
conflicts with my understanding of the text in RFC 3261 regarding the
use of the Require header and also seems to conflict with the definition
of the Refer-sub header in the draft since it would be quite valid to
send a Refer request with Require norefersub and Refer-sub True. A UAC
may require that the UAS support the extension for later requests on
that dialog without requesting Refer-sub False for that specific Refer
(possibly it may need to use Refer-sub True) for a later Refer request.

	I would propose that the text is either deleted or modified to:

	   The "norefersub" tag, when included in the Require header
field, 

	   specifies that the REFER-Recipient MUST support the extension
or

	   the REFER request MUST be rejected by sending "420 Bad
Extension" 

	   response back to the REFER-Issuer.

	Andrew

________________________________

	This transmission (including any attachments) may contain
confidential information, privileged material (including material
protected by the solicitor-client or other applicable privileges), or
constitute non-public information. Any use of this information by anyone
other than the intended recipient is prohibited. If you have received
this transmission in error, please immediately reply to the sender and
delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended
recipients is not authorized and may be unlawful. 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Wed, 26 Oct 2005 15:35:27 -0500

Orit and I discussed this, and we agree some clarification is in- 
order. I've asked orit to propose some text in RFC-ED before-after  
format, which we'll propose to include with the request for last call.

--
Dean

On Oct 25, 2005, at 6:26 PM, Orit Levin wrote:

> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Andrew Allen
> Subject: [Sip] Issue with draft-ietf-sip-refer-with-norefersub-03
>
> Orit
>
>
>
>    The "norefersub" tag, when included in the Require header field
>
>    (always in conjunction with the "Refer-Sub" header field set to
>
>    "false"), specifies that the REFER-Recipient MUST process a REFER
>
>    transaction without establishing an implicit subscription.  In this
>
>    is not willing to grant the request, the REFER request MUST be
>
>    rejected by sending "420 Bad Extension" response back to the REFER-
>
>    Issuer.
>
>
>
> assume that the reason why the Refer-sub header was added to the  
> draft was because the semantics for the use of Require header are  
> not to require a particular behavior other than to require that the  
> UAS support the extension(s) identified by the option tags in order  
> to accept the request containing the Require header.  The above  
> text from section 4 conflicts with my understanding of the text in  
> RFC 3261 regarding the use of the Require header and also seems to  
> conflict with the definition of the Refer-sub header in the draft  
> since it would be quite valid to send a Refer request with Require  
> norefersub and Refer-sub True. A UAC may require that the UAS  
> support the extension for later requests on that dialog without  
> requesting Refer-sub False for that specific Refer (possibly it may  
> need to use Refer-sub True) for a later Refer request.
>
>
>
>    The "norefersub" tag, when included in the Require header field,
>
>    specifies that the REFER-Recipient MUST support the extension or
>
>    the REFER request MUST be rejected by sending "420 Bad Extension"
>
> protected by the solicitor-client or other applicable privileges),  
> or constitute non-public information. Any use of this information  
> by anyone other than the intended recipient is prohibited. If you  
> have received this transmission in error, please immediately reply  
> to the sender and delete this information from your system. Use,  
> dissemination, distribution, or reproduction of this transmission  
> by unintended recipients is not authorized and may be unlawful.