Subject: [Sip] Reason draft

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 23 Apr 2002 13:10:43 +0300

Hi,

as previously suggested in the mailing list, I have removed the reason
specific codes from the Reason draft. Until it appears in the archives,
you can fetch it from:

http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-reason-00.txt

I would appreciate comments on the new format.

Thanks,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~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

---

From: AC Mahendran <[email-masked]>
Date: Tue, 23 Apr 2002 14:10:02 -0700

Gonzalo:

Section 2 of the draft states the following:
"A SIP message MAY contain more than one Reason values (i.e., multiple 
Reason lines), but all of them MUST have different protocol values (e.g., 
one SIP and another Q.850)"

Why is the restriction that the Reason values MUST have multiple protocol 
values ? For example, What if I want to provide multiple reasons (using the 
same protocol) as to why I am CANCELing a particular request ?

I don't see any need for having the restriction.

thanks,
AC

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 24 Apr 2002 08:19:34 +0300

Hello,

First of all, I need to fix the BNF in order to allow multiple Reason
lines. It will be fixed in the next release.

About your comment, which scenario do you have in mind for needing two
Reason codes using the same protocol? Could you provide us with a
particular example?

Thanks,

Gonzalo

---

From: AC Mahendran <[email-masked]>
Date: Wed, 24 Apr 2002 09:17:02 -0700

Gonzalo:

The 155 (Update Requested) response can definitely have multiple reasons.

For eg:  If authentication is required and at the same time the UAS doesn't 
support a particular extension in the request, the UAS can respond with two 
Reason codes:

Reason: SIP ;cause=401 ;text="Authentication needed"
Reason: SIP;cause=420  ;text="Bad Extension"

The corresponding headers, WWW-Authenticate & Unsupported, will provide 
more information needed in the UPDATE.

I really don't see the need in having this restriction in the specification.

thanks,
AC

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 25 Apr 2002 08:27:55 +0300

Hi,

well, in this case we would be providing functionality that does not
exist when we send a final response (rather than a 155).

Thefore, if we allow multiple Reason lines in a 155, it would be natural
to allow Reason also for final responses...

I would like to hear opinions about this.

Regards,

Gonzalo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Apr 2002 02:18:00 -0400

> I would like to hear opinions about this.

I would rather not allow this, for the reason Gonzalo cites. The normal
processing of a request does not allow multiple error reports in a
single response. Since the generation of 155 is based on following the
normal request processing, but just changing the value of the status
code, it should not be possible to see multiple error status codes in
the 155. 

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 25 Apr 2002 09:27:55 -0500

> I would like to hear opinions about this.

Currently in SIP, a non-2xx final response contains the reason why the
session failed (in case the request was establishing a session, to
begin with).  A non-2xx final response is *not* the aggregation of all
particular reasons why the response failed.  I think that allowing such
an aggregation would be an invitation to open a can of worms as one
figures out which headers to include/preclude in an aggregated response
(not to mention the receiving side, which will have to deduce what went
wrong based on presence/absence of such headers).

Furthermore, what if 2 things went wrong, but fixing one automatically
fixes the other (for instance, a UAS received a very long R-URI with an
unknown scheme, so it sends 2 Reason headers, one containing 414
"Request-URI too long" and the other 416 "Unsupported URI Scheme".  A
UAC may attempt to fix 414 by using an alternate shorter R-URI, which
just happens to be a URI that contains a scheme that the UAS
understands).

I think what the I-D says right now:

   "A SIP message MAY contain more than one Reason values (i.e.,
   multiple Reason lines), but all of them MUST have different
   protocol values (e.g., one SIP and another Q.850)"

should stand.  This mirrors the current response behavior in SIP.

Regards,

- vijay

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