Subject: Re: [Sip] Quick WGLC, Reason draft

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 02 May 2002 13:58:40 +0300

Vijay,

Thanks for the comments. Answers inline:

> Non-nits comments
> -----------------
> 1) The I-D says that:
>     "Initially, the Reason header field defined here appears to be
>      most useful for BYE and CANCEL requests, but it can appear in
>      any request"
> 
>     I seem to recall on the list that the Reason header field was limited
>     to requests within a dialog only.  Is this restriction no longer
>     applicable. 

Yes, it is still applicable. the paragraph now reads as follows:

"Initially, the \header{Reason} header field defined here appears to be
most
useful for {\BYE} and {\CANCEL} requests, but it can appear in any
request within a dialog, in any {\CANCEL} request and in 155 (Update
Requested) responses."

> 2) If I am not mistaken, the ABNF restricts the Reason field to appear
>     only once.  Since it can appear multiple times in a SIP message (and
>     be separable by commas), we should change the ABNF to reflect this.

Yes, I had already received this comment. the BNF now reads:

Reason            & = & "Reason" HCOLON reason-value *(COMMA
reason-value)\\
reason-value      & = & protocol *(SEMI reason-params)\\
protocol          & = & SIP $/$ Q.850 $/$ token\\
[...]

> 
> Nits comments
> -------------
> 1) The ABNF of Reason sets the Protocol field to:
>     Protocol = SIP / Q.850 / token
>     but the paragraph under the ABNF states that the value "SIP/2.0" has
>     been defined for a SIP status code.

This was a copy/paste error. Now it is fixed: SIP is used (rather than
SIP/2.0).

> 2) The following paragraph appears run-on:
>     "When an INVITE is rejected, not because the call is declined,
>     but because some aspect of the request was not acceptable, if
>     the INVITE was forked, the error response is not forwarded
>     towards the UAC by the forking proxy. This problem is known
>     as..."
>     Suggested modifications:
>     "An INVITE can sometimes be rejected not because the session
>     initiation was declined, but becuause some aspect of the request
>     was not acceptable; for instance, if the INVITE forked and
>     resulted in a rejection, which may never be forwarded to the
>     client unless all the other branches also reject the request.
>     This problem is known as ..."

Now it reads as follows:

"An INVITE can sometimes be rejected not because the session initiation
was declined, but because some aspect of the request was not acceptable.
If the INVITE forked and resulted in a rejection, the error response may
never be forwarded to the client unless all the other branches also
reject the request. This problem is known... "

> 
> 3) The four examples in Section 2 correspond roughly to the examples
>     of section 3.  Maybe they should be repeated (or presented for
>     the first time) in the relevant sub-sections of Section 3.

I believe it is alright as it is. It is good to provide examples about
the syntax right after the BNF. The rest of the examples are just call
flows that illustrate a bunch of possible scenarios.

Thanks for your comments,

Gonzalo

_______________________________________________
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