Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 May 2011 22:18:06 +0200

Hi,

199 responses is a real-life example.

A couple of days I suggested that we allow Reason headers with SIP response codes in SIP responses only if explicitly allowed for the response code of the SIP response.

And, if we agree to such way forward we don't need to specify anything new, because it's already allowed in RFC 3326:

   "The Reason header field MAY 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."

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Cullen Jennings [[email-masked]]
Sent: Monday, May 23, 2011 9:30 PM
To: Paul Kyzivat
Cc: DISPATCH list
Subject: Re: [dispatch] SIP responses carrying Q.850 cause values       in      Reason  header fields

It's pretty clear that we won't have interoperable systems unless the draft clearly says what to do in these cases. And I would like to +1 Martin's request for a real life example for any of this work. Please could the authors of the draft give us a real life example of how this all gets used in an itneroperable way.

On May 20, 2011, at 7:04 AM, Paul Kyzivat wrote:

>
>
> On 5/20/2011 8:48 AM, DOLLY, MARTIN C (ATTSI) wrote:
>> Paul,
>>
>> I do not understand your concern. Please give a REAL life example, not a what if.
>
> To start with, I am having difficulty understanding a use case for when you would *want* to send a sip reason code in a sip response.
>
> The motivation for the Reason header in the first place was to explain why a particular *request* was being sent.
>
> The justification for Q.850 reasons in *responses* is because the sip response codes don't carry all the nuances that the Q.850 codes do.
>
> Suppose I get SIP 486 response with a sip 503 reason code, or a sip 503 response code with a sip 486 reason code. What am I supposed to do with that? What does it *mean*?
>
>       Thanks,
>       Paul
>
>> Thank you,
>>
>> Martin Dolly
>> Lead Member Technical Staff
>> Core&  Government/Regulatory Standards
>> AT&T Services, Inc.
>> [email-masked]
>> +1-609-903-3360
>>
>>
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
>> Sent: Friday, May 20, 2011 8:45 AM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in Reason header fields
>>
>>
>>
>> On 5/20/2011 3:51 AM, [email-masked] wrote:
>>> Hi Paul,
>>> that was my understanding what Gonzalo proposed.
>>> He wanted to have it described as general approach. Without any restriction to ISUP Causes to be future proof.
>>>
>>> I have this send around a couple weeks ago. Nobody answered and I was in assumption that everybody agreed on this.
>>> Therefore I asked again for the agreement on the change again and what group name (DISPATCH? SIPCORE?) I should use for the next draft.
>>>
>>> I really don't care what way we go as long as we progress the draft properly and get the work done.
>>>
>>> I have 5 for progress with option 1 and one with don't care and you.
>>
>> The concern is that that sip reason codes in sip responses are like
>> having multiple responses to the same request. How should one behave?
>>
>> Fundamentally the problem isn't with the mechanics of delivering the
>> reason - its with the semantics of what has been sent. This has the
>> potential to lead to interoperation problems.
>>
>> We can let the chairs/ADs decide what to do.
>>
>>      Thanks,
>>      Paul
>>
>>> How to proceed now?
>>>
>>> Best Regards
>>>
>>> Roland
>>>
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: [email-masked]
>>>> [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
>>>> Gesendet: Donnerstag, 19. Mai 2011 15:12
>>>> An: [email-masked]
>>>> Betreff: Re: [dispatch] SIP responses carrying Q.850 cause
>>>> values in Reason header fields
>>>>
>>>> I am getting confused by all the options mentioned, to the
>>>> point that I
>>>> don't understand what is being proposed now.
>>>>
>>>> It *sounds* like you are proposing to allow *any* reason
>>>> (including sip
>>>> reason codes) in any response. I am concerned that that will cause
>>>> considerable confusion.
>>>>
>>>> I apologize if that is not what you are proposing.
>>>>
>>>>        Thanks,
>>>>        Paul
>>>>
>>>> On 5/19/2011 3:58 AM, [email-masked] wrote:
>>>>> Dear all,
>>>>> So assuming that there was no comment people are happy with
>>>> the new rewording I would like to prepare a new draft.
>>>>>
>>>>> This would be Option 1: General wording to allow the Reason
>>>> header within responses without any restrictions (except 100 Trying).
>>>>> And nobody wanted to have Option 2: Wording as stated in
>>>> the current draft
>>>>> draft-jesske-dispatch-update3326-reason-responses-02
>>>>>
>>>>> Agreed? Comments?
>>>>>
>>>>> Thank you and best Regards
>>>>>
>>>>> Roland
>>>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: Jesske, Roland
>>>>>> Gesendet: Donnerstag, 19. Mai 2011 09:50
>>>>>> An: Jesske, Roland
>>>>>> Betreff: AW: [dispatch] SIP responses carrying Q.850 cause
>>>>>> values in Reason header fields
>>>>>>
>>>>>>
>>>>>>
>>>>>>         On May 13, 2011, at 3:18 AM,<[email-masked]>    wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>> Since my answer it looks that people would be
>>>>>> OK with  the change.
>>>>>> So if no body comments within the next few days
>>>>>> I would prepare a new draft.
>>>>>>
>>>>>> So due to Gonzalo's proposal I would rewrite
>>>>>> the paragraphs as shown below.
>>>>>> For comparison reasons I have added also the
>>>>>> text proposal of the current draft
>>>>>> (draft-jesske-dispatch-update3326-reason-responses-02).
>>>>>> Please indicate which text you would like to
>>>>>> see finally. New proposal or current proposal.
>>>>>>
>>>>>>
>>>>>> 3.  RFC3326 1. Introduction
>>>>>>
>>>>>>     Original Text:
>>>>>>
>>>>>>     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.
>>>>>>
>>>>>>     New Text(new proposal):
>>>>>>
>>>>>>     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
>>>>>> independent of the protocol
>>>>>>     value used and in any response except 100 trying.
>>>>>>
>>>>>>     New Text (text stated in the current draft
>>>>>> draft-jesske-dispatch-update3326-reason-responses-02):
>>>>>>
>>>>>>     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
>>>>>> independent of the protocol
>>>>>>     value used and in any response except 100
>>>>>> trying if it contains only
>>>>>>     a Q.850 Cause Code.
>>>>>>
>>>>>> 4.  RFC3326 2. The Reason Header Field
>>>>>>
>>>>>>     Original Text
>>>>>>
>>>>>>     The Reason header field MAY 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jesske&    Liess           Expires October 2,
>>>>>> 2011                [Page 3]
>>>>>>
>>>>>> Internet-Draft                Reason Header
>>>>>>            March 2011
>>>>>>
>>>>>>
>>>>>>     New Text(new proposal):
>>>>>>
>>>>>>     The Reason header field  MAY appear
>>>>>>     in any request within a dialog, in any CANCEL
>>>>>> request .  The
>>>>>>     appearance of the Reason header field is
>>>>>> applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x
>>>>>>     and 199 provisional responses [I-D.ietf-sipcore-199].
>>>>>>
>>>>>>
>>>>>>     New Text(text stated in the current draft
>>>>>> draft-jesske-dispatch-update3326-reason-responses-02):
>>>>>>
>>>>>>     The Reason header field only containing a
>>>>>> Q.850 Cause Code MAY appear
>>>>>>     in any request within a dialog, in any CANCEL
>>>>>> request .  The
>>>>>>     appearance of the Reason header field only
>>>>>> containing a Q.850 Cause
>>>>>>     Code is applicable to final responses 3xx,
>>>>>> 4xx, 5xx and 6xx and 18x
>>>>>>     and 199 provisional responses [I-D.ietf-sipcore-199].
>>>>>>
>>>>>>     The Reason header field containing any other
>>>>>> reason value MAY 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>>
>>>>>> Roland
>>>>>>
>>>>>>
>>>>>> Deutsche Telekom Netzproduktion GmbH
>>>>>> Fixed Mobile Engineering Deutschland
>>>>>> Roland Jesske
>>>>>> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
>>>>>> +49 6151 628-2766 (Tel.)
>>>>>> +49 521 9210-3753  (Fax)
>>>>>> +49 171 8618-445  (Mobil)
>>>>>> E-Mail: mailto:[email-masked]
>>>>>> http://www.telekom.de
>>>>>>
>>>>>> Erleben, was verbindet.
>>>>>>
>>>>>> Deutsche Telekom Netzproduktion GmbH
>>>>>> Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
>>>>>> Geschäftsführung: Dr. Bruno Jacobfeuerborn
>>>>>> (Vorsitzender), Albert Matheis, Klaus Peren
>>>>>> Handelsregister: Amtsgericht Bonn HRB 14190
>>>>>> Sitz der Gesellschaft Bonn
>>>>>> USt-IdNr. DE 814645262
>>>>>>
>>>>>> Große Veränderungen fangen klein an -
>>>>>> Ressourcen schonen und nicht jede E-Mail drucken.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         -----Ursprüngliche Nachricht-----
>>>>>>
>>>>>>
>>>>>>                         Von: [email-masked]
>>>>>>
>>>>>>
>>>>>>                         [mailto:[email-masked]] Im
>>>>>> Auftrag von Jesske, Roland
>>>>>>
>>>>>>
>>>>>>                         Gesendet: Mittwoch, 6. April 2011 11:24
>>>>>>
>>>>>>
>>>>>>                         An: [email-masked];
>>>>>> [email-masked]
>>>>>>
>>>>>>
>>>>>>                         Betreff: Re: [dispatch] SIP responses
>>>>>> carrying Q.850 cause
>>>>>>
>>>>>>
>>>>>>                         values in Reason header fields
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         Hi Gonzalo,
>>>>>>
>>>>>>
>>>>>>                         I'm OK with your proposal so I could
>>>>>> change it if people
>>>>>>
>>>>>>
>>>>>>                         would like it.
>>>>>>
>>>>>>
>>>>>>                         It makes it shorter.
>>>>>>
>>>>>>
>>>>>>                         The only I would propose to have in is
>>>>>> the explicit
>>>>>>
>>>>>>
>>>>>>                         mentioning of the Response values due
>>>>>> to the fact that a
>>>>>>
>>>>>>
>>>>>>                         100OK or 200OK should not include a
>>>>>> Reason header with a
>>>>>>
>>>>>>
>>>>>>                         Q.850 Cause Value.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                         Best Regards
>>>>>>
>>>>>>
>>>>>>                         Roland Jesske
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                 -----Ursprüngliche Nachricht-----
>>>>>>
>>>>>>
>>>>>>                                 Von: [email-masked]
>>>>>>
>>>>>>
>>>>>>
>>>>>> [mailto:[email-masked]] Im Auftrag von Gonzalo Camarillo
>>>>>>
>>>>>>
>>>>>>                                 Gesendet: Dienstag, 5.
>>>> April 2011 14:03
>>>>>>
>>>>>>
>>>>>>                                 An: DISPATCH
>>>>>>
>>>>>>
>>>>>>                                 Betreff: [dispatch] SIP
>>>>>> responses carrying Q.850 cause values
>>>>>>
>>>>>>
>>>>>>                                 in Reason header fields
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                 Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                 last week in the DISPATCH
>>>>>> session, there was consensus to allow SIP
>>>>>>
>>>>>>
>>>>>>                                 responses to carry Reason
>>>>>> header fields with Q.850 cause
>>>>>>
>>>>>>
>>>>>>                         values. As I
>>>>>>
>>>>>>
>>>>>>                                 said some time ago, I am
>>>>>> willing to AD sponsor this draft
>>>>>>
>>>>>>
>>>>>>                         if/when the
>>>>>>
>>>>>>
>>>>>>                                 DISPATCH chairs confirm such
>>>>>> consensus on the list.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                 In the mean time, I have some
>>>>>> comments on how to document
>>>>>>
>>>>>>
>>>>>>                                 this decision.
>>>>>>
>>>>>>
>>>>>>                                 The following (fairly short)
>>>>>> draft updates a couple of
>>>>>>
>>>>>>
>>>>>>                                 paragraphs in RFC
>>>>>>
>>>>>>
>>>>>>                                 3326 in order to achieve the
>>>>>> desired outcome:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason
>>>>>> -responses-02.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                 I think this is not a
>>>>>> particularly elegant way to define
>>>>>>
>>>>>>
>>>>>>                         what we want.
>>>>>>
>>>>>>
>>>>>>                                 For example, if we wanted to
>>>>>> define a solution to HERFP in
>>>>>>
>>>>>>
>>>>>>                         the future
>>>>>>
>>>>>>
>>>>>>                                 based on the Reason header, we
>>>>>> would need to update those paragraphs
>>>>>>
>>>>>>
>>>>>>                                 again, making them longer every
>>>>>> time we added a new use case.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                 Instead, I would prefer to
>>>>>> explicitly define what we want
>>>>>>
>>>>>>
>>>>>>                         to do and be
>>>>>>
>>>>>>
>>>>>>                                 done with it. Such a (also
>>>>>> fairly short) draft would say
>>>>>>
>>>>>>
>>>>>>                                 something along
>>>>>>
>>>>>>
>>>>>>                                 the following lines:
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                 "RFC 3326 allows the presence
>>>>>> of the Reason header field in
>>>>>>
>>>>>>
>>>>>>                                 any response
>>>>>>
>>>>>>
>>>>>>                                 whose status code explicitly
>>>>>> allows its presence. This document
>>>>>>
>>>>>>
>>>>>>                                 explicitly allows any SIP
>>>>>> response to carry a Reason header
>>>>>>
>>>>>>
>>>>>>                                 field with a
>>>>>>
>>>>>>
>>>>>>                                 Q.850 cause value. SIP
>>>>>> responses with Reason header fields carrying
>>>>>>
>>>>>>
>>>>>>                                 values other than Q.850 cause
>>>>>> values are outside of the
>>>>>>
>>>>>>
>>>>>>                         scope of this
>>>>>>
>>>>>>
>>>>>>                                 document."
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                 I would like to know the
>>>>>> opinion of the WG on this matter
>>>>>>
>>>>>>
>>>>>>                                 (i.e., how to
>>>>>>
>>>>>>
>>>>>>                                 document the WG's consensus).
>>>>>> Note that reaching consensus was the
>>>>>>
>>>>>>
>>>>>>                                 difficult part. Agreeing on how
>>>>>> to document it should be easy.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                 Thanks,
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                 Gonzalo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>>
>>>>>>                                 dispatch mailing list
>>>>>>
>>>>>>
>>>>>>                                 [email-masked]
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> _______________________________________________
>>>>>>
>>>>>>
>>>>>>                         dispatch mailing list
>>>>>>
>>>>>>
>>>>>>                         [email-masked]
>>>>>>
>>>>>>
>>>>>>
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>>
>>>>>>
>>>>>>
>>>>>>                 _______________________________________________
>>>>>>                 dispatch mailing list
>>>>>>                 [email-masked]
>>>>>>                 https://www.ietf.org/mailman/listinfo/dispatch
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> dispatch mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>
>>>
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 May 2011 17:10:35 -0400

Christer,

Yes, we have been around that track a few times, and I'm ok with that 
case. Its independent of the other changes being proposed (unless they 
tread on the clause it depends upon.)

My concern was with allowing sip reason codes in all responses. And I 
think maybe Cullen is asking about the semantics of Q.850 codes in 
responses.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 May 2011 08:42:25 +0200

Hi,

>Yes, we have been around that track a few times, and I'm ok
>with that case. Its independent of the other changes being
>proposed (unless they tread on the clause it depends upon.)
>
>My concern was with allowing sip reason codes in all
>responses. And I think maybe Cullen is asking about the
>semantics of Q.850 codes in responses.

Ok. I thought we were talking explicitly about sip reason codes.

Sorry for the mess.

Regards,

Christer

> > A couple of days I suggested that we allow Reason headers
> with SIP response codes in SIP responses only if explicitly
> allowed for the response code of the SIP response.
> >
> > And, if we agree to such way forward we don't need to
> specify anything new, because it's already allowed in RFC 3326:
> >
> > From: [email-masked] [[email-masked]]
> On Behalf
> > Of Cullen Jennings [[email-masked]]
> > It's pretty clear that we won't have interoperable systems
> unless the draft clearly says what to do in these cases. And
> I would like to +1 Martin's request for a real life example
> for any of this work. Please could the authors of the draft
> give us a real life example of how this all gets used in an
> itneroperable way.
> >
> >
> >> To start with, I am having difficulty understanding a use
> case for when you would *want* to send a sip reason code in a
> sip response.
> >>
> >> The motivation for the Reason header in the first place
> was to explain why a particular *request* was being sent.
> >>
> >> The justification for Q.850 reasons in *responses* is
> because the sip response codes don't carry all the nuances
> that the Q.850 codes do.
> >>
> >> Suppose I get SIP 486 response with a sip 503 reason code,
> or a sip 503 response code with a sip 486 reason code. What
> am I supposed to do with that? What does it *mean*?
> >>
> >>        Thanks,
> >>        Paul
> >>
> >>> Thank you,
> >>>
> >>> Martin Dolly
> >>> From: [email-masked]
> [mailto:[email-masked]]
> >>> On Behalf Of Paul Kyzivat
> >>> Subject: Re: [dispatch] SIP responses carrying Q.850
> cause values in
> >>> Reason header fields
> >>>
> >>>
> >>>
> >>>> He wanted to have it described as general approach.
> Without any restriction to ISUP Causes to be future proof.
> >>>>
> >>>> I have this send around a couple weeks ago. Nobody
> answered and I was in assumption that everybody agreed on this.
> >>>> Therefore I asked again for the agreement on the change
> again and what group name (DISPATCH? SIPCORE?) I should use
> for the next draft.
> >>>>
> >>>> I really don't care what way we go as long as we
> progress the draft properly and get the work done.
> >>>>
> >>>>> Betreff: Re: [dispatch] SIP responses carrying Q.850
> cause values
> >>>>> in Reason header fields
> >>>>>
> >>>>> I am getting confused by all the options mentioned, to
> the point
> >>>>> that I don't understand what is being proposed now.
> >>>>>
> >>>>> (including sip reason codes) in any response. I am
> concerned that
> >>>>> that will cause considerable confusion.
> >>>>>
> >>>>>>> Since my answer it looks that people would be OK with  the
> >>>>>>> change.
> >>>>>>> So if no body comments within the next few days I
> would prepare
> >>>>>>> a new draft.
> >>>>>>>
> >>>>>>> So due to Gonzalo's proposal I would rewrite the
> paragraphs as
> >>>>>>> shown below.
> >>>>>>> For comparison reasons I have added also the text proposal of
> >>>>>>> the current draft
> >>>>>>> Please indicate which text you would like to see finally. New
> >>>>>>> proposal or current proposal.
> >>>>>>>
> >>>>>>>
> >>>>>>>      Initially, the Reason header field defined here
> appears to
> >>>>>>> be most
> >>>>>>>      useful for BYE and CANCEL requests, but it can appear in
> >>>>>>> any request
> >>>>>>> whose
> 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.
> >>>>>>>
> >>>>>>>      New Text(new proposal):
> >>>>>>>
> >>>>>>>      Initially, the Reason header field defined here
> appears to
> >>>>>>> be most
> >>>>>>>      useful for BYE and CANCEL requests, but it can appear in
> >>>>>>> any request
> >>>>>>>      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 independent of the
> >>>>>>> protocol
> >>>>>>>      value used and in any response except 100 trying if it
> >>>>>>> contains only
> >>>>>>>      a Q.850 Cause Code.
> >>>>>>>
> >>>>>>>      in any request within a dialog, in any CANCEL request .
> >>>>>>> The
> >>>>>>>      appearance of the Reason header field is applicable to
> >>>>>>> final responses 3xx, 4xx, 5xx and 6xx and 18x
> >>>>>>>      The Reason header field only containing a Q.850
> Cause Code
> >>>>>>> MAY appear
> >>>>>>>      in any request within a dialog, in any CANCEL request .
> >>>>>>> The
> >>>>>>>      appearance of the Reason header field only containing a
> >>>>>>> Q.850 Cause
> >>>>>>>      Code is applicable to final responses 3xx, 4xx,
> 5xx and 6xx
> >>>>>>> and 18x
> reason value
> >>>>>>> MAY appear
> request and
> >>>>>>> in any
> >>>>>>>      response whose status code explicitly allows the
> presence
> >>>>>>> of this
> >>>>>>>      header field.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Best Regards
> >>>>>>>
> >>>>>>>
> >>>>>>> Roland
> >>>>>>>
> >>>>>>>
> >>>>>>> Deutsche Telekom Netzproduktion GmbH Fixed Mobile Engineering
> >>>>>>> Deutschland Roland Jesske Heinrich-Hertz-Straße 3-7, 64295
> >>>>>>> Darmstadt
> >>>>>>> +49 6151 628-2766 (Tel.)
> >>>>>>> +49 521 9210-3753  (Fax)
> >>>>>>> +49 171 8618-445  (Mobil)
> >>>>>>> E-Mail: mailto:[email-masked] http://www.telekom.de
> >>>>>>>
> >>>>>>> Erleben, was verbindet.
> >>>>>>>
> >>>>>>> Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender),
> >>>>>>> Albert Matheis, Klaus Peren
> >>>>>>> Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der
> >>>>>>> Gesellschaft Bonn USt-IdNr. DE 814645262
> >>>>>>>
> >>>>>>> Große Veränderungen fangen klein an - Ressourcen schonen und
> >>>>>>> nicht jede E-Mail drucken.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>

---

From: <[email-masked]>
Date: Tue, 24 May 2011 15:30:47 +0200

Dear all,
after messing up the whole group with the discussion in how to finalise Draft.
I went back to some proposals within the past.
I don't care if we generalise it or restrict it to Q.850. As long as we get the work done.
After the whole discussion within the last days I at least came to the result to restrict it to Q.850 causes.

So I have two proposals.

1. As it is defined within http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason-responses-02.txt

2. Instead of having an update of Section 1 and 2 in RFC3326 only stating.

"RFC 3326 allows the presence of the Reason header field in any response
whose status code explicitly allows its presence. This document
explicitly allows any SIP response to carry a Reason header field with a
Q.850 cause value. SIP responses with Reason header fields carrying
values other than Q.850 cause values are outside of the scope of this
document."

Please comment and vote for one of the both.

Thank you and Best Regards

Roland

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 24 May 2011 15:43:11 +0200

Hi Roland,

I would slightly prefer your new proposal 2 but could also accept your
new proposal 1.

Differences are minor and a matter of taste.

What really counts is that this draft is finalized.

Thomas

---------------------------------- 
Dr. Thomas Belling 
3GPP Standardisation
Nokia Siemens Networks 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext [email-masked]
Sent: Tuesday, May 24, 2011 3:31 PM
To: [email-masked]
Subject: Re: [dispatch] SIP responses carrying Q.850 cause values in
Reason header fields

Dear all,
after messing up the whole group with the discussion in how to finalise
Draft.
I went back to some proposals within the past.
I don't care if we generalise it or restrict it to Q.850. As long as we
get the work done.
After the whole discussion within the last days I at least came to the
result to restrict it to Q.850 causes.

So I have two proposals.

1. As it is defined within
http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason-responses
-02.txt

2. Instead of having an update of Section 1 and 2 in RFC3326 only
stating.

Roland

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 May 2011 15:50:39 +0200

Hi,

I also support proposal 2), but would not object to 1).

I just want to get this done.

Regards,

Christer 

> [mailto:[email-masked]] On Behalf Of Belling, 
> Thomas (NSN - DE/Munich)
> Sent: 24. toukokuuta 2011 16:43
> To: [email-masked]; [email-masked]
> I would slightly prefer your new proposal 2 but could also 
> accept your new proposal 1.
> 
> [mailto:[email-masked]] On Behalf Of ext 
> [email-masked]
> After the whole discussion within the last days I at least 
> came to the result to restrict it to Q.850 causes.
> 
> So I have two proposals.
> 
-responses
> "RFC 3326 allows the presence of the Reason header field in 
> any response whose status code explicitly allows its 
> presence. This document explicitly allows any SIP response to 
> carry a Reason header field with a Q.850 cause value. SIP 
> responses with Reason header fields carrying values other 
> than Q.850 cause values are outside of the scope of this document."
>