Subject: [Sip] Quick WGLC, Reason draft

From: "Dean Willis" <[email-masked]>
Date: Sat, 27 Apr 2002 05:25:18 -0500

We need to process the Reason draft. The UPDATE method is dependent on
it.

http://search.ietf.org/internet-drafts/draft-ietf-sip-reason-00.txt

Editor Gonzalo Camarillo will coordinate responses -- please copy him.

Thanks,

--
Dean Willis

_______________________________________________
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: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 29 Apr 2002 09:24:41 -0500

> Editor Gonzalo Camarillo will coordinate responses -- please copy him.

Gonzalo:

Some comments, divided into nits and non-nits comments.

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.  The I-D implies that a request generated, for instance,
    by a 3PCC controller establishing a session with party B may contain
    a Reason header.

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.

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.  However, the examples still
    contain the value "SIP", not "SIP/2.0".  To be consistent, we should
    either mention the value "SIP" in the paragraph below the ABNF, or
    change the ABNF and examples to contain "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 ..."

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.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216