Subject: Re: [SIP] comments on draft-ietf-sip-100rel-01.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 01 Jun 2000 01:45:12 -0400

Thanks for your comments. Responses below:

"Schroeder, Tim" wrote:
> 
> Section 3, Paragraph 1: "Note that a UAS MUST NOT send a response reliably
> unless there was a Supported header in the request indicating support for
> this extension."
> 
> This should be "... unless there was a Supported or Require header in the
> request indicating support for this extension."

Fixed.

> 
> -----
> 
> Section 3, Paragraph 3: "The UAC can determine that the response is to be
> transmitted reliably by the presence of the RSeq header."
> 
> I believe this should read "... by the presence of a Require header
> containing the option tag 100rel."  The use of the Require header in the
> response is mandated (correctly, in my opinion) by Section 5.2, Paragraph 6
> (UAS behavior).  This also follows draft-ietf-sip-serverfeatures-02.txt
> which "allows for the Require header to appear in responses. It is used to
> indicate what options must be understood by the UAC in order to process the
> response."
> In general, I think it's best to explicitly state what extensions/features
> are being used, rather than having the user agent deduce them from the
> presence/absence of headers.  This also will allow the Rseq header to be
> reused in other extensions where it might make sense, rather than having to
> create another extension-specific header.

Good point. Fixed.

> 
> -----
> 
> Section 5.1, Paragraph 2: "The rest of this discussion assumes this header
> has been inserted into a request."
> 
> This should read "... one of these headers has been inserted ...".  The
> previous paragraph was improved to allow for the UAC to insert either the
> Supported header or the Require header, and this sentence needs to follow
> suit.

Fixed.

> 
> -----
> 
> Section 5.1, Paragraph 11: "It is not necessary to include the Supported
> header listing the option tag 100rel in the PRACK request."
> 
> I disagree.  Given that the UAS may try to send reliable provisional
> responses to a PRACK (it's mentioned, and seems reasonable for completeness,
> though I don't see an obvious use of this), I think the UAC ought to say
> whether it supports or requires the 100rel feature.  Yes, the UAS can deduce
> that the feature is supported by the presence of the PRACK method, but (1)
> the UAS cannot tell from the existence of the PRACK method whether the UAC
> *requires* or merely *supports* the 100rel feature, and (2) the PRACK method
> could never be used in support of any other feature.  (2) might not be much
> of a problem, but I think either a Require or Supported header is needed to
> address (1).  Mandating the header would also make PRACK more consistent
> with the other methods, all of which mandate either the Require or Supported
> header.

Given the change that you can't send a reliable provisional response to
PRACK, it seems this text is actually fine - its not needed to include
this Supported header in PRACK.

> 
> -----
> 
> Section 5.2, Paragraph 1: "The UAS may send any provisional response
> reliably, so long as the initial request contained a Supported header
> indicating that this feature is understood."
> 
> This should read "... the initial request contained either a Supported or
> Require header indicating that this feature is understood."

Actually, not quite, since the strengths are different. It now reads:

The UAS \MAY send any provisional response reliably, so long as the
initial request contained a \header{Supported} header indicating
that this feature is understood. The UAS \MUST send any non-100
response reliably if the initial request contained a \header{Require}
header indicating that the feature is mandatory for all provisional
responses. If the UAS is unwilling to do so, it \MUST reject the
initial request with a 420 (Bad Extension) and include a
\header{Unsupported} header containing the option tag {\sf 100rel}. 

> 
> -----
> 
> Lastly (and maybe I've missed my chance on this one, since the "open issue"
> section went away), did we ever come up with an application where the
> cumulative response mechanism was needed?  I thought we had come to
> consensus to drop it unless there was a demonstrated need (which I haven't
> seen, though I may have just missed it).

At the meeting, I thought we had decided to keep it, but there wasn't a
whole lot of comment, and I am willing to entertain arguments for
removing it. I can think of applications where its useful (using
provisionals for call queue status, and having several changes all sent
in rapid succession). 

> 
> The UAC must PRACK a provisional response, which seems to disallow
> accumulating responses in the hopes of sending one PRACK for the group.

That is a good point, and we would need to change that to SHOULD if this
mechanism stays.

> Only if a provisional response arrives which is known to be out-of-sequence,
> and only if it is then cached by the UAC, and only if the previous missing
> response then arrives, does it seem that the cumulative response mechanism
> could come into play.  The examples section uses "two provisional responses
> in rapid succession" to address this, but I'm not sure that's sufficient.
> When the first response arrives, I read section 5.1 (UAC behavior) to
> require that the UAC construct and send a PRACK; I'm not sure waiting around
> to see if another response arrives before doing so is reasonable -- it would
> delay the acknowledgement of the first response in the usually vain hope
> that another response would quickly arrive. 

THis is no different than data buffering in any stream oriented protocol
- you wait for so long and then send.

 Maybe if the two responses were
> sent together in a single UDP packet, the cumulative response would be
> justified?
> 
> Also, the last paragraph of section 3 and the penultimate paragraph of
> section 5.2 both recommend that a UAS wait for acknowledgement of a
> provisional response before sending the next one.  Any UAS following this
> recommended procedure would certainly never need the cumulative response
> mechanism.

The mechanism is for the benefit of the UAC, in the case where this
recommendation is not followed.

> 
> I'd take out all the verbiage dealing with the cumulative responses, in the
> interests of simplicity and clarity. 

Any other opinions on this?

> There'd no longer need to be any
> difference in handling between the first reliable response (which cannot be
> part of a cumulative group because of the need to agree on the first Rseq)
> and any further reliable responses.  

I think that is a different issue.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip