Subject: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses

From: <[email-masked]>
Date: Thu, 28 Jan 2010 08:16:11 +0100

Dear all,
The discussion at the last IETF meeting due to the proposal to use the reason header within responses where controversial.

I would like to start the discussion on mentioned concerns.

One concern was that we define an new encapsulation mechanism for ISUP elements in parallel to SIP-T.

The Reason header itself is a SIP generic Header defined in RFC3326.

The syntax allows to put in a SIP Response code and/or an ISUP Q.850 Cause Code.

As many times mentioned before RFC 3326 (The Reason Header Field for the Session Initiation Protocol (SIP)) defines the following.

   Initially, the 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 any response whose
   status code explicitly allows the presence of this header field.

   Note that the Reason header field is usually not needed in responses
   because the status code and the reason phrase already provide
   sufficient information.

   Clients and servers are free to ignore this header field.  It has no
   impact on protocol processing.

At that time where RFC3326 was written it was not assumed that a Reason in a response is usually not needed but it does not restrict the use of the Reason header within responses. It allows the use of the Reason header if the status code allows it.

That was the reasoning for writing this draft to allow the Reason header within Responses and it is not an new encapsulation mechanism.

Kind regards
Roland Jesske

Deutsche Telekom Netzproduktion GmbH
Technical Engineering Center
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt, Germany
+49 6151 628-2766 (Phone)
+49 521 9210-3753  (Fax)
+49 171 8618-445  (Mobile)
E-Mail: [email-masked]
www.telekom.com

Life is for sharing.

Deutsche Telekom Netzproduktion GmbH
Supervisory Board: Dr. Steffen Roehn (Chairman)
Managing Board: Dr. Bruno Jacobfeuerborn (Chairman), Albert Matheis, Klaus Peren
Commercial register: Local court Bonn HRB 14190
Registered office: Bonn
VAT identification no. DE 814645262

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Jan 2010 15:40:15 +0100

I think the long discussion we had at IETF#76 was out of all proportion to the magnitude of the proposed change.

The Reason header field is a rather ugly solution to a problem brought about by incompatible sets of reason codes in these two different protocols. But given that we have the Reason header field, and that it is already allowed in some requests and responses, I don't really see the harm in opening the door to use in other responses. We could put some caveats around it, to try to discourage inappropriate uses. However, somebody implementing primarily for a SIP environment is unlikely to use (or abuse) this header field, which I would expect to be used only where really needed.

Why can't we just let the people who want this get on and do it, and save our precious discussion time for more important topics?

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 28 January 2010 07:16
> To: [email-masked]
> Subject: [dispatch] ISSUES on 
> draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in 
> Responses
> 
> Dear all, 
> The discussion at the last IETF meeting due to the proposal 
> to use the reason header within responses where controversial.
> 
> As many times mentioned before RFC 3326 (The Reason Header 
> Field for the Session Initiation Protocol (SIP)) defines the 
> following.
> 
> At that time where RFC3326 was written it was not assumed 
> that a Reason in a response is usually not needed but it does 
> not restrict the use of the Reason header within responses. 
> It allows the use of the Reason header if the status code allows it.
> 
> That was the reasoning for writing this draft to allow the 
> Reason header within Responses and it is not an new 
> encapsulation mechanism.
> 
> Kind regards 
> Roland Jesske 
> 
> 
> E-Mail: [email-masked] <mailto:[email-masked]>  
> www.telekom.com <http:www.telekom.com>  
> 
> Life is for sharing. 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Jan 2010 10:08:45 -0500

> Why can't we just let the people who want this get on and do it, and save our precious discussion time for more important topics?

I wasn't there for the discussion. :-(

I generally agree with John that this is pretty benign.

The one concern I have is if somebody implements in such a way that 
these reason codes must be in responses for proper operation, thus 
making native SIP devices understand and populate this data to get good 
results.

	Thanks,
	Paul

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: <[email-masked]>
Date: Fri, 29 Jan 2010 08:37:02 +0100

Hi Paul,
That was never the intend of the draft.

It is already mentioned within RFC 3326:
   Clients and servers are free to ignore this header field.  It has no
   impact on protocol processing.

And we can write something in addition within the draft to clarify that. 
It is NOT the scope that native SIP devices either populate nor act on a received Reason with a Q.850 cause.

Kind regards
Roland Jesske

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
Gesendet: Donnerstag, 28. Januar 2010 16:09
An: Elwell, John
Cc: [email-masked]; Jesske, Roland
Betreff: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 29 Jan 2010 11:20:35 +0100

+1 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: 28. tammikuuta 2010 16:40
To: [email-masked]; [email-masked]
Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses

John 

> The discussion at the last IETF meeting due to the proposal to use the 
> reason header within responses where controversial.
> 
> As many times mentioned before RFC 3326 (The Reason Header Field for 
> the Session Initiation Protocol (SIP)) defines the following.
> 
> At that time where RFC3326 was written it was not assumed that a 
> Reason in a response is usually not needed but it does not restrict 
> the use of the Reason header within responses.
> That was the reasoning for writing this draft to allow the Reason 
> header within Responses and it is not an new encapsulation mechanism.
> 
> Kind regards
> Roland Jesske
> 
> 
> Supervisory Board: Dr. Steffen Roehn (Chairman) Managing Board: Dr. 
> Bruno Jacobfeuerborn (Chairman), Albert Matheis, Klaus Peren 
> Commercial register: Local court Bonn HRB 14190 Registered office: 
> Bonn VAT identification no. DE 814645262
> 
>

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 29 Jan 2010 12:28:36 +0100

+1 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Christer Holmberg
Sent: Friday, January 29, 2010 11:21 AM
To: 'Elwell, John'; [email-masked]; [email-masked]
Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: 28. tammikuuta 2010 16:40
To: [email-masked]; [email-masked]
Subject: Re: [dispatch] ISSUES on draft-jesske-dispatch-reason-in-responses-01 -- Use Reason in Responses

John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Jan 2010 09:58:02 -0500

> That was never the intend of the draft.

I didn't think it was the intent.
But its amazing what people will do.

>    impact on protocol processing.

Ah, I had forgotten that.

> It is NOT the scope that native SIP devices either populate nor act on a received Reason with a Q.850 cause.

Maybe the above is enough. But restating it wouldn't hurt.

	Thanks,
	Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 29 Jan 2010 10:50:58 -0600

Hi, Roland,

I agree with Paul here - restating this point, with the pointer to RFC 3326, 
is worth doing.

I wasn't at the mike in Hiroshima on this topic, but I was in the room, and 
anything that reduces the chances of another conversation like that one on 
this topic is well worth doing!

Thanks,

Spencer