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

From: "Schroeder, Tim" <[email-masked]>
Date: Wed, 31 May 2000 10:10:55 -0500

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."
 
-----
 
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.
 
-----
 
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.
 
-----
 
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.
 
-----
 
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."
 
-----
 
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).  
 
The UAC must PRACK a provisional response, which seems to disallow
accumulating responses in the hopes of sending one PRACK for the group.
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.  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.  
 
I'd take out all the verbiage dealing with the cumulative responses, in the
interests of simplicity and clarity.  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.  Maybe the space freed up in the
examples session could be used to show an example with the Require: 100rel
header rather than the Supported: 100rel header.
 
Apologies if I missed some resolution on this cumulative response issue.
 
-----

Tim Schroeder 
[email-masked] 
SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX  78759 

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