Subject: [dispatch] Update on draft-jesske-dispatch-reason-in-responses

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Jan 2011 16:18:14 -0700

Sent with my dispatch co-chair hat on 

I went back and reviewed the mailing list traffic and what I could find of meeting minutes and recording related to this draft. 

The major contentious issues are:  Should the solution be based on translation or encapsulation, and in the encapsulation case deciding if an existing encapsulation mechanism should be used or new one defined

There are several people in favor of this draft: Roland , Christer, Hadriel, Laura, Thomas, Christen, Enrico, John, Dale, and probably a few more. 

This was discussed for a long time at IETF 76 ( See http://www.softarmor.com/dispatch/IETF76/audio/reason.mp3 ). It did not get consensus at that point. The issues brought up at that point have not been resolved on the list. None of the people that spoke for or against this at IETF 76 seem to have changed their opinion on the list. As far as I can tell, the list of people in favor of this and people opposed to it is pretty much the same list as it was at IETF 76. The directions from the DISPATCH chairs at IETF 76 (at about 40 minutes into above recording) have not happened yet. 

There was not rough consensus at IETF 76 to proceed with this, I see no evidence that many peoples options have changed since IETF 76. I view it as pretty much dispatched. (in the definition 2a at http://www.merriam-webster.com/dictionary/dispatched). 

My advice the ADs about AD sponsoring would be that this draft was controversial in the WG, failed to achieve rough consensus, and was highly likely to have strongly objections in an IETF Last Call. 

A casual observation to the proponents of this work ... using translation in the form of new SIP error response codes, instead of encapsulation, may be the middle ground that everyone could live with and achieved consensus. Even if theses response codes would never be used outside of environment that interoperated with the PSTN. I realize that neither the people for or against this draft view new SIP error response codes as the best path forward so this idea may be doomed but some times the thing everyone can live with is the solution no one loves. 

This work goes back far enough that it is a bit of an archaeology project to sort out the information so if my read of the consensus at IETF 76 is completely wrong, I'm happy to have someone correct me. 

Thanks, 
Cullen <dispatch co-chair>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 21 Jan 2011 11:13:34 +0200

Hi Cullen,

thanks for the summary! I was the actual DISPATCH chair declaring that
there was no consensus at that point, as reflected in the recordings.
However, at the end of the meeting it was pointed out that many people
may have been confused about what exactly RFC 3326 said and what was the
change being proposed.

This is what RFC 3326 says about the possibility of Reason header fields
appearing in responses:

http://tools.ietf.org/html/rfc3326

> 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.

So, RFC 3326 allows Reason header fields in responses as long as it is
specified which responses can carry it. The reason for this is that, at
that point, it was believed that a solution to the Heterogeneous Error
Response Forking Problem was going to be based on having a particular
provisional response carry final error responses in Reason header
fields. Such a solution was never fully specified, as we all know.

With respect to final responses carrying Reason header fields, there was
no use case at that point. However, people agreed it would not be good
to have two final error codes, one in the status line and a different
one in a Reason header field. However, adding a different type of code
(e.g., a Q.850 code) to a final response was not discussed... and that
is what is being proposed now.

The other discussion point was whether or not encapsulating a REL
message in a final response (using SIP-T or SIP-I) would be a better
alternative to carrying the Q.850 code in a Reason header field. The
authors explained that there were use cases that did not involve two
gateways. Instead, they involved a SIP application server that was ISUP
aware. An explanation of the use case can be found in the following draft:

http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-responses-02#section-5

The other draft related to this discussion is the following:

http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses-03

With all this information in mind, I am OK with discussing what to do
with this issue on this list. The important thing here is that the WG
makes an *educated* decision and that we stick to it. The alternatives
are to agree that this needs to be done (the actual specification could
be AD sponsored, for instance) or to agree that we do not want to do
this so that we do not spend any more cycles on it in the future.

Thanks,

Gonzalo

On 20/01/2011 1:18 AM, Cullen Jennings wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 21 Jan 2011 18:15:50 +0100

One thing to consider is that this has been around in 3GPP standards for
so long that is already in the field and to my knowledge is also already
used in many deployments outside 3GPP (for instance, I3forum liked that
very much).

Thus this is very likely not to disappear out of real SIP deployments no
matter what IETF decides. 

In that sense it may be preferable to document the reality.

BR, Thomas

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Gonzalo Camarillo
Sent: Friday, January 21, 2011 10:14 AM
To: Cullen Jennings
Cc: DISPATCH list
Subject: Re: [dispatch] Update on
draft-jesske-dispatch-reason-in-responses

Hi Cullen,

aware. An explanation of the use case can be found in the following
draft:

http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-responses
-02#section-5

Thanks,

Gonzalo

On 20/01/2011 1:18 AM, Cullen Jennings wrote:
> I went back and reviewed the mailing list traffic and what I could
find of meeting minutes and recording related to this draft. 
> 
> The major contentious issues are:  Should the solution be based on 
> translation or encapsulation, and in the encapsulation case deciding 
> if an existing encapsulation mechanism should be used or new one 
> defined
> 
> There are several people in favor of this draft: Roland , Christer,
Hadriel, Laura, Thomas, Christen, Enrico, John, Dale, and probably a few
more. 
> 
> This was discussed for a long time at IETF 76 ( See
http://www.softarmor.com/dispatch/IETF76/audio/reason.mp3 ). It did not
get consensus at that point. The issues brought up at that point have
not been resolved on the list. None of the people that spoke for or
against this at IETF 76 seem to have changed their opinion on the list.
As far as I can tell, the list of people in favor of this and people
opposed to it is pretty much the same list as it was at IETF 76. The
directions from the DISPATCH chairs at IETF 76 (at about 40 minutes into
above recording) have not happened yet. 
> 
> There was not rough consensus at IETF 76 to proceed with this, I see
no evidence that many peoples options have changed since IETF 76. I view
it as pretty much dispatched. (in the definition 2a at
http://www.merriam-webster.com/dictionary/dispatched). 
> 
> My advice the ADs about AD sponsoring would be that this draft was
controversial in the WG, failed to achieve rough consensus, and was
highly likely to have strongly objections in an IETF Last Call. 
> 
> A casual observation to the proponents of this work ... using
translation in the form of new SIP error response codes, instead of
encapsulation, may be the middle ground that everyone could live with
and achieved consensus. Even if theses response codes would never be
used outside of environment that interoperated with the PSTN. I realize
that neither the people for or against this draft view new SIP error
response codes as the best path forward so this idea may be doomed but
some times the thing everyone can live with is the solution no one
loves. 
> 
> This work goes back far enough that it is a bit of an archaeology
project to sort out the information so if my read of the consensus at
IETF 76 is completely wrong, I'm happy to have someone correct me.

---

From: <[email-masked]>
Date: Mon, 24 Jan 2011 11:31:48 +0100

Hi Cullen,
thank you for your comments with regard to the  draft-jesske-dispatch-reason-in-responses.

Yes the draft was controversially discussed at IETF 76.
With regard to the discussion at that meeting we had a follow up discussion that was held at the dispatch list.

So I worked mainly on the requirements to satisfy the people.

With the upload of the following two drafts I tried to satisfy the latest discussions we had on the list.

http://www.ietf.org/internet-drafts/draft-jesske-dispatch-reason-in-responses-03.txt

http://www.ietf.org/internet-drafts/draft-jesske-dispatch-req-reason-in-responses-02.txt

The first draft describes the requirements and the behaviour for the reason in responses. I have added a section for requirements again, as it was proposed from a couple of people. The requirements section is very short and  exists of two requirements.

The 2nd draft is more seen for documentation reasons and examples and is not aimed for further processing.

Since I started the discussion on the list after IETF 76 I never seen/heard objections with regard to progressing the drafts.

Also I would like to point out that 3GPP is requiring the reason in responses within the IMS.

Also ITU-T Q.1912.5 includes the use of reasons in responses. This ITU-T recommendation was published 2003.
Also ETSI TISPAN is using the reason in responses since 2006 in their Standards.

So there are already implementations running with the reason in responses. We as Deutsche Telekom have already running implementations from 3 different vendors.

So my question is if the group is now willing to go ahead with the work on this issue or would like to live with the implementations without any RFC?

So again I would like to invite the people to indicate their support for that work if we should proceed ether with a WID or some individual action.

Thank you and Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Cullen Jennings
> Gesendet: Donnerstag, 20. Januar 2011 00:18
> An: DISPATCH list
> Betreff: [dispatch] Update on
> I went back and reviewed the mailing list traffic and what I
> could find of meeting minutes and recording related to this draft.
>
> The major contentious issues are:  Should the solution be
> based on translation or encapsulation, and in the
> encapsulation case deciding if an existing encapsulation
> mechanism should be used or new one defined
>
> There are several people in favor of this draft: Roland ,
> Christer, Hadriel, Laura, Thomas, Christen, Enrico, John,
> Dale, and probably a few more.
>
> http://www.softarmor.com/dispatch/IETF76/audio/reason.mp3 ).
> It did not get consensus at that point. The issues brought up
> at that point have not been resolved on the list. None of the
> people that spoke for or against this at IETF 76 seem to have
> changed their opinion on the list. As far as I can tell, the
> list of people in favor of this and people opposed to it is
> pretty much the same list as it was at IETF 76. The
> directions from the DISPATCH chairs at IETF 76 (at about 40
> minutes into above recording) have not happened yet.
>
> There was not rough consensus at IETF 76 to proceed with
> this, I see no evidence that many peoples options have
> changed since IETF 76. I view it as pretty much dispatched.
> (in the definition 2a at
> My advice the ADs about AD sponsoring would be that this
> draft was controversial in the WG, failed to achieve rough
> consensus, and was highly likely to have strongly objections
> in an IETF Last Call.
>
> translation in the form of new SIP error response codes,
> instead of encapsulation, may be the middle ground that
> everyone could live with and achieved consensus. Even if
> theses response codes would never be used outside of
> environment that interoperated with the PSTN. I realize that
> neither the people for or against this draft view new SIP
> error response codes as the best path forward so this idea
> may be doomed but some times the thing everyone can live with
> is the solution no one loves.
>
> This work goes back far enough that it is a bit of an
> archaeology project to sort out the information so if my read
> of the consensus at IETF 76 is completely wrong, I'm happy to
> have someone correct me.
>
> Thanks,

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 24 Jan 2011 15:21:27 +0100

I still think this draft is worth publishing as an RFC by some route. It reflects what is often done in practice and I don't see why it should be considered harmful.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 24 January 2011 10:32
> To: [email-masked]; [email-masked]
> thank you for your comments with regard to the  
> draft-jesske-dispatch-reason-in-responses.
> 
> With regard to the discussion at that meeting we had a follow 
> up discussion that was held at the dispatch list.
> 
> With the upload of the following two drafts I tried to 
> satisfy the latest discussions we had on the list.
> 
> The first draft describes the requirements and the behaviour 
> for the reason in responses. I have added a section for 
> requirements again, as it was proposed from a couple of 
> people. The requirements section is very short and  exists of 
> two requirements.
> 
> The 2nd draft is more seen for documentation reasons and 
> examples and is not aimed for further processing.
> 
> Since I started the discussion on the list after IETF 76 I 
> never seen/heard objections with regard to progressing the drafts.
> 
> Also ITU-T Q.1912.5 includes the use of reasons in responses. 
> This ITU-T recommendation was published 2003.
> So there are already implementations running with the reason 
> in responses. We as Deutsche Telekom have already running 
> implementations from 3 different vendors.
> 
> So my question is if the group is now willing to go ahead 
> with the work on this issue or would like to live with the 
> implementations without any RFC?
> 
> So again I would like to invite the people to indicate their 
> support for that work if we should proceed ether with a WID 
> or some individual action.
>

---

From: <[email-masked]>
Date: Mon, 24 Jan 2011 15:35:37 +0100

+1

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la
> part de Elwell, John
> Envoyé : lundi 24 janvier 2011 15:21
> À : [email-masked]; [email-masked]; [email-masked]
> Objet : Re: [dispatch] Update on draft-jesske-dispatch-reason-in-
> responses
> 
> I still think this draft is worth publishing as an RFC by some route.
> It reflects what is often done in practice and I don't see why it
> should be considered harmful.
> 
> John
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Jan 2011 15:52:11 +0100

+1.

Regards,

Christer 

> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 24. tammikuuta 2011 16:36
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> > De : [email-masked] 
> [mailto:[email-masked]] De 
> > la part de Elwell, John Envoyé : lundi 24 janvier 2011 15:21 À : 
> > [email-masked]; [email-masked]; [email-masked] 
> Objet : Re: 
> > [dispatch] Update on draft-jesske-dispatch-reason-in- responses
> > 
> > > With regard to the discussion at that meeting we had a follow up 
> > > discussion that was held at the dispatch list.
> > >
> > > The first draft describes the requirements and the 
> behaviour for the 
> > > reason in responses. I have added a section for 
> requirements again, 
> > > as it was proposed from a couple of people. The 
> requirements section 
> > > is very short and  exists of two requirements.
> > >
> > > Since I started the discussion on the list after IETF 76 I never 
> > > seen/heard objections with regard to progressing the drafts.
> > >
> > > Also I would like to point out that 3GPP is requiring the 
> reason in 
> > > responses within the IMS.
> > >
> > > So there are already implementations running with the reason in 
> > > responses. We as Deutsche Telekom have already running 
> with the 
> > > work on this issue or would like to live with the implementations 
> > > without any RFC?
> > >
> > > So again I would like to invite the people to indicate 
> their support 
> > > for that work if we should proceed ether with a WID or some 
> > > individual action.
> > >
> > > > translation or encapsulation, and in the encapsulation case 
> > > > deciding if an existing encapsulation mechanism should 
> be used or 
> > > > new one defined
> > > >
> > > > Christer, Hadriel, Laura, Thomas, Christen, Enrico, John, Dale, 
> > > > and probably a few more.
> > > >
> > > > It did not get consensus at that point. The issues 
> brought up at 
> > > > that point have not been resolved on the list. None of 
> the people 
> > > > that spoke for or against this at IETF 76 seem to have changed 
> > > > their opinion on the list. As far as I can tell, the list of 
> > > > people in favor of this and people opposed to it is pretty much 
> > > > the same list as it was at IETF 76. The directions from the 
> > > > DISPATCH chairs at IETF 76 (at about 40 minutes into above 
> > > > recording) have not happened yet.
> > > >
> > > > There was not rough consensus at IETF 76 to proceed 
> with this, I 
> > > > see no evidence that many peoples options have changed 
> since IETF 
> > > > 76. I view it as pretty much dispatched.
> > > > (in the definition 2a at
> > > > controversial in the WG, failed to achieve rough consensus, and 
> > > > was highly likely to have strongly objections in an IETF Last 
> > > > Call.
> > > >
> > > > translation in the form of new SIP error response 
> codes, instead 
> > > > of encapsulation, may be the middle ground that everyone could 
> > > > live with and achieved consensus. Even if theses response codes 
> > > > would never be used outside of environment that 
> interoperated with 
> > > > the PSTN. I realize that neither the people for or against this 
> > > > draft view new SIP error response codes as the best 
> path forward 
> > > > so this idea may be doomed but some times the thing 
> everyone can 
> > > > live with is the solution no one loves.
> > > >
> archaeology 
> > > > project to sort out the information so if my read of 
> the consensus 
> > > > at IETF 76 is completely wrong, I'm happy to have 
> someone correct 
> > > > me.
> > > >
> > > > Thanks,

---

From: Laura Liess <[email-masked]>
Date: Mon, 24 Jan 2011 16:59:33 +0100

+1

Thanks,
Laura

2011/1/24 Elwell, John <[email-masked]>:
>> reason in responses within the IMS.
>>

---

From: Lili Yang_lili <[email-masked]>
Date: Mon, 24 Jan 2011 16:05:34 +0000

+1

Best reggards,
Lili
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Laura Liess [[email-masked]]
发送时间: 2011年1月24日 23:59
到: [email-masked]; [email-masked]; [email-masked]
主题: Re: [dispatch] Update on draft-jesske-dispatch-reason-in-responses

+1

Thanks,
Laura

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 24 Jan 2011 17:35:03 +0100

+1

Regards, Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Lili Yang_lili
Sent: Monday, January 24, 2011 5:06 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] Update on draft-jesske-dispatch-reason-in-responses

+1

Best reggards,
Lili

+1

Thanks,
Laura

2011/1/24 Elwell, John <[email-masked]>:
>> The first draft describes the requirements and the behaviour for the 
>> reason in responses. I have added a section for requirements again, 
>> as it was proposed from a couple of people. The requirements section 
>> So my question is if the group is now willing to go ahead with the 
>> So again I would like to invite the people to indicate their support 
>> > deciding if an existing encapsulation mechanism should be used or 
>> > new one defined
>> >
>> > Hadriel, Laura, Thomas, Christen, Enrico, John, Dale, and probably 
>> > a few more.
>> >
>> > It did not get consensus at that point. The issues brought up at 
>> > that point have not been resolved on the list. None of the people 
>> > their opinion on the list. As far as I can tell, the list of people 
>> > in favor of this and people opposed to it is pretty much the same 
>> > list as it was at IETF 76. The directions from the DISPATCH chairs 
>> > at IETF 76 (at about 40 minutes into above recording) have not 
>> > happened yet.
>> >
>> > There was not rough consensus at IETF 76 to proceed with this, I 
>> > see no evidence that many peoples options have changed since IETF 
>> > encapsulation, may be the middle ground that everyone could live 
>> > with and achieved consensus. Even if theses response codes would 
>> > never be used outside of environment that interoperated with the 
>> > PSTN. I realize that neither the people for or against this draft 
>> > view new SIP error response codes as the best path forward so this 
>> > idea may be doomed but some times the thing everyone can live with 
>> > project to sort out the information so if my read of the consensus 
>> > at IETF 76 is completely wrong, I'm happy to have someone correct 
>> > me.
>> >
>> > Thanks,

---

From: Mary Barnes <[email-masked]>
Date: Mon, 24 Jan 2011 11:15:47 -0600

Roland,

I think the reason that there is always some debate when this topic is
discussed is because there are really two parts.

One is the "allowing" of the Reason header in responses.  The drafts (i.e.,
abstracts) posit that the document(s) "specifies and formally permits the
use of the Reason Header field in SIP responses..."  which implies normative
changes to RFC 3326 and there is some RFC 2119 language in the first draft
(although not in caps).  This leads one to believe that this work intends to
Update RFC 3326.    As Gonzalo clearly laid out, we had the long debate as
to whether RFC 3326   already allows the reason header in responses.   So,
if we want this to be an informational document, it needs to be clear in
that document that this does not make any normative changes to RFC, but
rather describes the use of Reason in responses.  And, it would seem that in
the latter case, examples would be helpful, which leads to the second part.

The folks that are in support of this draft seem to really be in support of
the enabling of the functionality that is in your second draft.  Cullen laid
out the past concerns raised about the solution in his email on the
encapsulation versus translation discussion.

So, it would be really helpful if the +1 folks could highlight whether their
+ 1 is with regards to clarifying the use of the Reason header or whether
they are agreeing with the solution proposal for the use cases in the second
document.  If the latter (or if the +1 is for both), then explaining why
they believe that the approach is the best way to solve the problem would be
helpful (beyond the fact that other SDOs are doing it this way).

Regards,
Mary.
DISPATCH WG co-chair

On Mon, Jan 24, 2011 at 4:31 AM, <[email-masked]> wrote:

> The first draft describes the requirements and the behaviour for the reason
> in responses. I have added a section for requirements again, as it was
> proposed from a couple of people. The requirements section is very short and
>  exists of two requirements.
>
> Since I started the discussion on the list after IETF 76 I never seen/heard
> objections with regard to progressing the drafts.
>
> So there are already implementations running with the reason in responses.
> We as Deutsche Telekom have already running implementations from 3 different
> vendors.
>
> So my question is if the group is now willing to go ahead with the work on
> this issue or would like to live with the implementations without any RFC?
>
> So again I would like to invite the people to indicate their support for
> that work if we should proceed ether with a WID or some individual action.
>

---

From: "Calme, James A (Jim)" <[email-masked]>
Date: Mon, 24 Jan 2011 11:16:17 -0600

+1

BR,
Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Belling, Thomas (NSN - DE/Munich)
Sent: Monday, January 24, 2011 10:35 AM
To: DISPATCH list
Subject: Re: [dispatch] Update on draft-jesske-dispatch-reason-in-responses

+1

Regards, Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Lili Yang_lili
Sent: Monday, January 24, 2011 5:06 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] Update on draft-jesske-dispatch-reason-in-responses

+1

Best reggards,
Lili

+1

Thanks,
Laura

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 24 Jan 2011 15:06:41 -0500

From: Mary Barnes [[email-masked]]
> One is the "allowing" of the Reason header in responses.  The drafts
> (i.e., abstracts) posit that the document(s) "specifies and formally
> permits the use of the Reason Header field in SIP responses..."  which
> implies normative changes to RFC 3326 and there is some RFC 2119
> language in the first draft (although not in caps).  This leads one to
> believe that this work intends to Update RFC 3326.  As Gonzalo clearly
> laid out, we had the long debate as to whether RFC 3326 already allows
> the reason header in responses.  So, if we want this to be an
> informational document, it needs to be clear in that document that
> this does not make any normative changes to RFC, but rather describes
> the use of Reason in responses.  And, it would seem that in the latter
> case, examples would be helpful, which leads to the second part.

In regard to this point, I am in favor of allowing Reason in responses
generally.  That does support the specific use cases, but will also be
useful in other circumstances.

Since, strictly speaking, RFC 3326 does not permit Reason in responses,
this would have to be a normative change to RFC 3326.

> The folks that are in support of this draft seem to really be in
> support of the enabling of the functionality that is in your second
> draft.

I am also in favor of using Reason with "Q.850" values as a solution
to the problems discussed in the drafts.  Alone, that would be an
informative document, as Q.850 values are already specified by RFC
3326.

> Cullen laid out the past concerns raised about the solution in
> his email on the encapsulation versus translation discussion.

Could you give us a pointer to that e-mail?  It's not recent enough
for me to easily find it, but you seem to know where it is.  If I
could read it, it would clarify the situation for me.

For the record, it appears that 12 people are counted as being in
favor of this proposal: the 9 listed in Cullen's e-mail, Bruno
Chatras, LiLi Yang, and James Calme.  Not to mention the 3GPP industry
collectively, whatever weight we wish to assign them.  Who is against
this proposal?

Dale

---

From: Mary Barnes <[email-masked]>
Date: Mon, 24 Jan 2011 15:56:40 -0600

Hi Dale,

Responses inline below [MB].

Regards,
Mary.

> could read it, it would clarify the situation for me.
[MB]  Cullen posted the email on Jan 19th:
http://www.ietf.org/mail-archive/web/dispatch/current/msg03196.html
[/MB]

> collectively, whatever weight we wish to assign them.  Who is against
[MB] The question I have is what do you mean by "this proposal" - i.e., I
had asked the folks that responded +1 exactly what they were in favor of?
1) Reason header in responses - i.e., Update RFC 3326
2) Solving the use cases in the same manner as has been done for other SDOs
3) Both 1) and 2)

The reason I ask is because Roland had suggest that only this document needs
progressing and that document focuses on item 1 (although it duplicates
requirements from the other document below):
http://datatracker.ietf.org/doc/draft-jesske-dispatch-reason-in-responses/

The other document describes the use of the Reason header for specific use
cases and per my email, there has been debate as to whether the solution is
the right approach:
http://www.ietf.org/id/draft-jesske-dispatch-req-reason-in-responses-02.txt
(this is really a requirements use case and solution document that
takes
advantage of the changes defined by 1)

[/MB]

---

From: Georg Mayer <[email-masked]>
Date: Tue, 25 Jan 2011 01:05:15 +0100

Add my "1" as well please!

Thanks & Greetings,
Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lili Yang_lili
Sent: Montag, 24. Januar 2011 17:06
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] Update on draft-jesske-dispatch-reason-in-responses

+1

Best reggards,
Lili
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Laura
Liess [[email-masked]]
发送时间: 2011年1月24日 23:59
到: [email-masked]; [email-masked]; [email-masked]
主题: Re: [dispatch] Update on draft-jesske-dispatch-reason-in-responses

+1

Thanks,
Laura

2011/1/24 Elwell, John <[email-masked]>:
> I still think this draft is worth publishing as an RFC by some route. It
reflects what is often done in practice and I don't see why it should be
considered harmful.

---

From: "Andrew Allen" <[email-masked]>
Date: Tue, 25 Jan 2011 01:24:53 -0600

+1 from me.

Andrew

----- Original Message -----
From: Georg Mayer [mailto:[email-masked]]
Sent: Monday, January 24, 2011 06:05 PM
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [dispatch] Update on draft-jesske-dispatch-reason-in-responses

Thanks & Greetings,
Georg

-----Original Message-----

+1

Best reggards,
Lili

+1

Thanks,
Laura

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Jan 2011 09:20:20 +0100

Hi, 

>Not to mention the 3GPP industry collectively, whatever weight we 
>wish to assign them.  

I guess the agreement between IETF and 3GPP should provide some guidance on that.

Regards,

Christer

---

From: <[email-masked]>
Date: Tue, 25 Jan 2011 10:01:27 +0100

Hi Mary,
the people supporting the draft, I think don't care about the documentation. As long as the reason within responses will be allowed.

Until now I had the assumption that the way I'm going with my draft is the inline with what we discussed around the issue.

So doing two steps back and looking on RFC3326 the following sentence shows the problem.

*****RFC3326 SNIP
SNAP ****

Until now I was thinking that it would be proper enough to write an draft with one page to say that this RFCxxxx endorses RFC3326 with the following procedure.

The appearance of the Reason header is applicable to final responses  3xx, 4xx, 5xx and 6xx and 18x and 199 provisional responses.

That would be one page and you don't have to touch RFC3326. And it would be backward compatible for equipment only supporting the reason header within the scope of RFC3326.

The other text around was only describing the reasoning and was trying to satisfy people who wanted to see more text. And I thought that this was the assumption how to go.

But I could also write an draft RFC3326bis by replacing the sentence above by deleting the last words.:

  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.

That's it.

Nevertheless http://www.ietf.org/id/draft-jesske-dispatch-reason-in-responses-03.txt will give more background why the use of reason in responses is allowed and also some procedures are described.

I don't care about the documentation as long as we have agreement to start the work.

Best Regards

Roland

  _____

Von: Mary Barnes [mailto:[email-masked]]
Gesendet: Montag, 24. Januar 2011 18:16
An: Jesske, Roland
Cc: [email-masked]; [email-masked]
Betreff: Re: [dispatch] Update on draft-jesske-dispatch-reason-in-responses

Roland,

I think the reason that there is always some debate when this topic is discussed is because there are really two parts.

One is the "allowing" of the Reason header in responses.  The drafts (i.e., abstracts) posit that the document(s) "specifies and formally permits the use of the Reason Header field in SIP responses..."  which implies normative changes to RFC 3326 and there is some RFC 2119 language in the first draft (although not in caps).  This leads one to believe that this work intends to Update RFC 3326.    As Gonzalo clearly laid out, we had the long debate as to whether RFC 3326   already allows the reason header in responses.   So, if we want this to be an informational document, it needs to be clear in that document that this does not make any normative changes to RFC, but rather describes the use of Reason in responses.  And, it would seem that in the latter case, examples would be helpful, which leads to the second part.

The folks that are in support of this draft seem to really be in support of the enabling of the functionality that is in your second draft.  Cullen laid out the past concerns raised about the solution in his email on the encapsulation versus translation discussion.

So, it would be really helpful if the +1 folks could highlight whether their + 1 is with regards to clarifying the use of the Reason header or whether they are agreeing with the solution proposal for the use cases in the second document.  If the latter (or if the +1 is for both), then explaining why they believe that the approach is the best way to solve the problem would be helpful (beyond the fact that other SDOs are doing it this way).

Regards,
Mary.
DISPATCH WG co-chair

On Mon, Jan 24, 2011 at 4:31 AM, <[email-masked]<mailto:[email-masked]>> wrote:

Hi Cullen,

Roland

> Von: [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]<mailto:[email-masked]>] Im Auftrag von Cullen Jennings

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

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 Jan 2011 10:01:56 +0100

Mary,

I am one of those who spoke in favour of progressing draft-jesske-dispatch-reason-in-responses. I think it can be generally useful (e.g., to give a more explicit reason in conjunction with a provisional response such as 181). I don't want to write a new RFC each time such a use case arises, but I would prefer to have a generic solution.

The particular use cases in draft-jesske-dispatch-req-reason-in-responses were not my main motivation.

Moreover, I am not convinced we need to update RFC 3326, which already permits the Reason header field in "any response whose status code explicitly allows the presence of this header field". It seems to be just a matter of having a Standards Track RFC that names all response codes (or a sufficiently large set to cover reasonable needs) as being able to be accompanied by a Reason header field.

John

> [mailto:[email-masked]] On Behalf Of Mary Barnes
> Sent: 24 January 2011 17:16
> To: [email-masked]
> Cc: [email-masked]
> I think the reason that there is always some debate when this 
> topic is discussed is because there are really two parts. 
> 
> One is the "allowing" of the Reason header in responses.  The 
> drafts (i.e., abstracts) posit that the document(s) 
> "specifies and formally permits the use of the Reason Header 
> field in SIP responses..."  which implies normative changes 
> to RFC 3326 and there is some RFC 2119 language in the first 
> draft (although not in caps).  This leads one to believe that 
> this work intends to Update RFC 3326.    As Gonzalo clearly 
> laid out, we had the long debate as to whether RFC 3326   
> already allows the reason header in responses.   So, if we 
> want this to be an informational document, it needs to be 
> clear in that document that this does not make any normative 
> changes to RFC, but rather describes the use of Reason in 
> responses.  And, it would seem that in the latter case, 
> examples would be helpful, which leads to the second part.   
> 
> The folks that are in support of this draft seem to really be 
> in support of the enabling of the functionality that is in 
> your second draft.  Cullen laid out the past concerns raised 
> about the solution in his email on the encapsulation versus 
> translation discussion.  
> 
> So, it would be really helpful if the +1 folks could 
> highlight whether their + 1 is with regards to clarifying the 
> use of the Reason header or whether they are agreeing with 
> the solution proposal for the use cases in the second 
> document.  If the latter (or if the +1 is for both), then 
> explaining why they believe that the approach is the best way 
> to solve the problem would be helpful (beyond the fact that 
> other SDOs are doing it this way).  
> 
> Regards,
> Mary. 
> DISPATCH WG co-chair
> 
> 	With regard to the discussion at that meeting we had a 
> follow up discussion that was held at the dispatch list.
> 	
> behaviour for the reason in responses. I have added a section 
> for requirements again, as it was proposed from a couple of 
> 	The 2nd draft is more seen for documentation reasons 
> and examples and is not aimed for further processing.
> 	
> 	Since I started the discussion on the list after IETF 
> 76 I never seen/heard objections with regard to progressing 
> the drafts.
> 	
> 	Also ITU-T Q.1912.5 includes the use of reasons in 
> responses. This ITU-T recommendation was published 2003.
> 	So there are already implementations running with the 
> reason in responses. We as Deutsche Telekom have already 
> running implementations from 3 different vendors.
> 	
> 	So my question is if the group is now willing to go 
> ahead with the work on this issue or would like to live with 
> the implementations without any RFC?
> 	
> their support for that work if we should proceed ether with a 
> WID or some individual action.
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 25 Jan 2011 10:32:33 +0100

+1

/Hans Erik van Elburg

On Mon, Jan 24, 2011 at 3:21 PM, Elwell, John <
[email-masked]> wrote:

> > http://www.ietf.org/internet-drafts/draft-jesske-dispatch-reas
> on-in-responses-03.txt<http://www.ietf.org/internet-drafts/draft-jesske-dispatch-reas%0Aon-in-responses-03.txt>
> >

---

From: "Patel, Milan" <[email-masked]>
Date: Tue, 25 Jan 2011 04:56:28 -0500

+1

Regards,
Milan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Calme, James A (Jim)
Sent: Monday, January 24, 2011 5:16 PM
To: Belling, Thomas (NSN - DE/Munich); DISPATCHlist
Subject: Re: [dispatch] Update on draft-jesske-dispatch-reason-in-responses

+1

BR,
Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Belling, Thomas (NSN - DE/Munich)
Sent: Monday, January 24, 2011 10:35 AM
To: DISPATCH list
Subject: Re: [dispatch] Update on draft-jesske-dispatch-reason-in-responses

+1

Regards, Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Lili Yang_lili
Sent: Monday, January 24, 2011 5:06 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] Update on draft-jesske-dispatch-reason-in-responses

+1

Best reggards,
Lili

+1

Thanks,
Laura

2011/1/24 Elwell, John <[email-masked]>:
> on-in-responses-03.txt

Milan Patel 
Consultant
InterDigital Communications, LLC

Tel.: +44 7917 678 250
Fax: 
Email: [email-masked]
http://www.InterDigital.com

This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.

---

From: Laura Liess <[email-masked]>
Date: Tue, 25 Jan 2011 15:23:26 +0100

Hi Mary,

My +1 was mainly for Reason header in responses, with or without
updating RFC 3326. This means the first part from 1). It seems to me
that reason in responses already are or are planned to be used not
only by carriers and their vendors for Q.850 reasons, but also by SIP
PBX vendors, as a general mechanism to provide more details than it is
possible using only the response code.

I have no strong opinion about whether updating RFC 3326 is necessary
or not. However, if not updating it could lead in the end to
interoperability problems in the field because different people have
different opinions if Reason in responses is allowed or not, we should
do the update.

Thanks
Laura

2011/1/24 Mary Barnes <[email-masked]>:
>  (this is really a requirements use case and solution document that takes

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jan 2011 10:37:19 -0500

> Moreover, I am not convinced we need to update RFC 3326, which already permits the Reason header field in "any response whose status code explicitly allows the presence of this header field". It se…

Well, while such a "blanket" RFC sounds attractive in some ways, ISTM 
that it is really a much bigger change than an update to 3326.
In effect its an update to 3261 *and* every other RFC that defines a 
response code.

Updating RFC 3326 to permit a reason in responses is a much more 
straightforward way to make the change.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Wed, 26 Jan 2011 10:39:45 +0100

> In effect its an update to 3261 *and* every other RFC that defines a

Sorry Paul I do not understand this. If I follow the mythology it looks for me that each new header introduced for SIP updates then RFC3261. because it could also influences also all Responses if such an header is allowed to be included in all responses.

E.G looking on  RFC3323 I found this:
   Header field          where   proxy ACK BYE CAN INV OPT REG
   ___________________________________________________________
   Privacy                        amrd  o   o   o   o   o   o

   Header field                        SUB NOT PRK IFO UPD MSG
   ___________________________________________________________
   Privacy                              o   o   o   o   o   o

So does now RFC3323 updates RFC3261 *and* every other RFC that defines a
response code. Because the pricy header could appear in each Response.

> straightforward way to make the change.

So you would like to see an update to RFC3326 which would be then it is a one page RFC. Updating section 1. and Section 2. saying that Reason header is allowed in all responses.

So I counted +1 for an update to RFC3326 and +1 for the approach as shown in my draft.

Thanks

Roland

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 26 Jan 2011 12:16:31 +0100

Paul,

I don't follow your argument that a blanket RFC allowing Reason in any response, or a large set of responses, would mean an update to RFC 3261. However, if the conclusion is that updating RFC 3326 is a more pragmatic way to go, I don't mind.

John 

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 25 January 2011 15:37
> To: [email-masked]
> > I am one of those who spoke in favour of progressing 
> draft-jesske-dispatch-reason-in-responses. I think it can be 
> generally useful (e.g., to give a more explicit reason in 
> conjunction with a provisional response such as 181). I don't 
> want to write a new RFC each time such a use case arises, but 
> I would prefer to have a generic solution.
> >
> > The particular use cases in 
> draft-jesske-dispatch-req-reason-in-responses were not my 
> main motivation.
> >
> > Moreover, I am not convinced we need to update RFC 3326, 
> which already permits the Reason header field in "any 
> response whose status code explicitly allows the presence of 
> this header field". It seems to be just a matter of having a 
> Standards Track RFC that names all response codes (or a 
> sufficiently large set to cover reasonable needs) as being 
> able to be accompanied by a Reason header field.
>

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 17:00:09 +0100

Dear all,
a couple of days we discussed how to proceed with the reason in responses.

As I see we have enough support for going ahead. But which approach should we take. (Mary asked this question also on Monday)

1. write an UPDATE to RFC 3326
2. progress draft-jesske-dispatch-reason-in-responses

Currently I have seen the following opinions:

For solution 1. +1 Paul
For solution 2. + Laura
1 or 2 don't mind +1 John

As long as the draft is already existing I would have my preference to go for 1.
But if needed I can also create an UPDATE to RFC3326.

So please indicate your solution you would like to see.

Roland

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 17:17:08 +0100

I have a slight preference for solution 2 "progress draft-jesske-dispatch-reason-in-responses". 

> part de [email-masked]
> Envoyé : jeudi 27 janvier 2011 17:00
> À : [email-masked]
> Objet : [dispatch] Update fo RFC3326 or draft-jesske-dispatch-reason-
> in-responses approach
> 
> 
> Dear all,
> As I see we have enough support for going ahead. But which approach
> should we take. (Mary asked this question also on Monday)
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 27 Jan 2011 17:23:20 +0100

+1

/Hans Erik van Elburg

On Thu, Jan 27, 2011 at 5:17 PM, <[email-masked]> wrote:

> I have a slight preference for solution 2 "progress
> draft-jesske-dispatch-reason-in-responses".
>
>
>

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 17:31:55 +0100

So to clarify my opinion below.
used the wrong number.

As long as the draft is already existing I have my
preference to go for 2.

that is the problem using too easy numbering.

Sorry

> [mailto:[email-masked]] Im Auftrag von Jesske, Roland
> Gesendet: Donnerstag, 27. Januar 2011 17:00
> An: [email-masked]
> Betreff: [dispatch] Update fo RFC3326 or
> draft-jesske-dispatch-reason-in-responses approach
>
>
> Dear all,
> As I see we have enough support for going ahead. But which
> approach should we take. (Mary asked this question also on Monday)
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Jan 2011 17:34:13 +0100

I prefer solution 2.

Regards,

Christer 

> Sent: 27. tammikuuta 2011 18:00
> To: [email-masked]
> Subject: [dispatch] Update fo RFC3326 or

---

From: Lili Yang_lili <[email-masked]>
Date: Thu, 27 Jan 2011 16:41:51 +0000

I also prefer solution 2. 

Please +1 for solution 2.

Best regards,
Lili 
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Christer Holmberg [[email-masked]]
发送时间: 2011年1月28日 0:34
到: [email-masked]; [email-masked]
主题: Re: [dispatch] Update fo RFC3326 or draft-jesske-dispatch-reason-in-responses approach

I prefer solution 2.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2011 12:03:12 -0500

I can live with either way.

	Thanks,
	Paul

---

From: "Patel, Milan" <[email-masked]>
Date: Thu, 27 Jan 2011 12:05:08 -0500

Hello,

+1 for solution 2. 
Regards,
Milan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lili Yang_lili
Sent: Thursday, January 27, 2011 4:42 PM
To: Christer Holmberg; [email-masked]; [email-masked]
Subject: [dispatch] 答复: Update fo RFC3326 or draft-jesske-dispatch-reason-in-responses approach

Best regards,
Lili 

I prefer solution 2.

Regards,

Christer

 

Milan Patel 
Consultant

Tel.: +44 7917 678 250
Fax:

---

From: Laura Liess <[email-masked]>
Date: Thu, 27 Jan 2011 18:08:28 +0100

Hi Roland,

Maybe I was not quite clear with my answer.

My strong opinion is that we should allow the Reason-header in
responses as a general mechanisms, as Dale required, not just look for
a solution for the use cases described in your drafts. Concerning the
RFC 3326 I still have no realy strong opinion. However, also an update
for 3326 would take much longer, this way you would get the Reason
header in responses as Proposed Standard instead of informational and
probably avoid discussions and interoperability problems in the
future.

So, count my vote  for 1), but I can live with 2).

Laura

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 27 Jan 2011 22:36:45 +0530

Hi Roland,
 
I look into draft-jesske-dispatch-req-reason-in-responses-02 requirement. By reading your requirement document, it looks like that RFC 3398 does not distinguish each of the Q.850 to SIP responses. It leads to wrong response code in PSTN--SIP--PSTN topology. In case the proper mapping exist between Q.850 to SIP response, the problem *may* be solved. Pls correct me in case I misunderstand your requirement document.
 
I agree that Q.850 cause code in SIP response solves the problem for PSTN--SIP--PSTN network but ISTM protocol hack as there are two response codes exist in the same response and the two response codes are mutually exclusive in one occasion and different in other occasion.
 
Eg:  1) In single response msg, same response in two form 
 
   503 SIP msg response with 41 as Q.850 cause code
 
2) In single response msg, Different responses 
  
   503 SIP msg response with 34 as Q.850 cause code
 
This could be avoided in case the proper mapping exist. Please let me know your opinion here.
 
Thanks
Partha

________________________________

From: [email-masked] on behalf of Paul Kyzivat (pkyzivat)
Sent: Thu 1/27/2011 10:33 PM
To: [email-masked]
Subject: Re: [dispatch] Update fo RFC3326 or draft-jesske-dispatch-reason-in-responses approach

        Thanks,
        Paul

---

From: Mary Barnes <[email-masked]>
Date: Thu, 27 Jan 2011 11:09:37 -0600

The problem is that the current wording in the draft implies an update to
RFC 3326 - i.e., it states:
      This document

   specifies and formally permits the use of the Reason header field in
   SIP responses to carry Q.850 reason codes for this and other
   purposes.

So, the question isn't whether to progress the draft per se but whether the
implication of the functionality you describe is a normative change RFC 3326
(i.e., UPDATES) or whether an informational draft is sufficient.  I would
posit that if this work is progressed as informational, then it should be
restricted to describing the use of SIP responses to carry the Q.850 reason
codes and drop the the "other purposes". And, you need to remove the
normative RFC 2119 language.   In other words, if folks do not believe an
update to RFC 3326 is necessary then the drafts needs to be revised to limit
the scope and be quite clear that it is informational.

Regards,
Mary.

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 27 Jan 2011 18:38:34 +0100

+1 for solution 2

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Patel, Milan
Sent: Thursday, January 27, 2011 6:05 PM
To: [email-masked]; [email-masked]
Subject: Re: [dispatch] 答复: Update fo RFC3326 or draft-jesske-dispatch-reason-in-responses approach

Hello,

+1 for solution 2. 
Regards,
Milan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lili Yang_lili
Sent: Thursday, January 27, 2011 4:42 PM
To: Christer Holmberg; [email-masked]; [email-masked]
Subject: [dispatch] 答复: Update fo RFC3326 or draft-jesske-dispatch-reason-in-responses approach

Best regards,
Lili

I prefer solution 2.

Regards,

Christer

 

Milan Patel
Consultant

Tel.: +44 7917 678 250
Fax:

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 18:18:16 +0000

Hi Mary,

I am not an expert on IETF procedures, but as it was already said that the contents of the draft has been already implemented, then hopefully we can we find an easy way to document that history, please?

Whether that will have an additional knock-on effect elsewhere should of course be considered, but that should not become the blocking point on documenting something that happened already.

BR,
Hannu Hietalahti
3GPP TSG CT Chairman
tel: +358 40 5021724

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Mary Barnes
Sent: 27 January, 2011 19:10
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dispatch] Update fo RFC3326 or draft-jesske-dispatch-reason-in-responses approach

The problem is that the current wording in the draft implies an update to RFC 3326 - i.e., it states:
      This document

So, the question isn't whether to progress the draft per se but whether the implication of the functionality you describe is a normative change RFC 3326 (i.e., UPDATES) or whether an informational draft is sufficient.  I would posit that if this work is progressed as informational, then it should be restricted to describing the use of SIP responses to carry the Q.850 reason codes and drop the the "other purposes". And, you need to remove the normative RFC 2119 language.   In other words, if folks do not believe an update to RFC 3326 is necessary then the drafts needs to be revised to limit the scope and be quite clear that it is informational.

Regards,
Mary.

On Thu, Jan 27, 2011 at 10:31 AM, <[email-masked]<mailto:[email-masked]>> wrote:
So to clarify my opinion below.
used the wrong number.

Sorry

> [mailto:[email-masked]<mailto:[email-masked]>] Im Auftrag von Jesske, Roland
> An: [email-masked]<mailto:[email-masked]>

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 28 Jan 2011 09:16:25 +0100

+1 for solution 2

Christian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Belling, Thomas (NSN - DE/Munich)
Sent: Thursday, January 27, 2011 6:39 PM
To: [email-masked]
Subject: Re: [dispatch] 答复: Update fo RFC3326 or draft-jesske-dispatch-reason-in-responses approach

+1 for solution 2

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Patel, Milan
Sent: Thursday, January 27, 2011 6:05 PM
To: [email-masked]; [email-masked]
Subject: Re: [dispatch] 答复: Update fo RFC3326 or draft-jesske-dispatch-reason-in-responses approach

Hello,

+1 for solution 2. 
Regards,
Milan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lili Yang_lili
Sent: Thursday, January 27, 2011 4:42 PM
To: Christer Holmberg; [email-masked]; [email-masked]
Subject: [dispatch] 答复: Update fo RFC3326 or draft-jesske-dispatch-reason-in-responses approach

Best regards,
Lili

I prefer solution 2.

Regards,

Christer

 

Milan Patel
Consultant

Tel.: +44 7917 678 250
Fax:

---

From: <[email-masked]>
Date: Fri, 28 Jan 2011 14:11:49 +0100

Hi Mary,
until now it looked for me it is the decision of people which way they want to go.
So seeing from your mail I see that there an UPDATE to RFC3326 would be more convenient and my other draft could help to have some reasoning/use cases.

So I have Uploaded an draft proposing an UPDATE to RFC3326.

http://www.ietf.org/id/draft-jesske-dispatch-update3326-reason-responses-00.txt

Comments are welcome.

Best Regards

Roland

  _____

Von: Mary Barnes [mailto:[email-masked]]
Gesendet: Donnerstag, 27. Januar 2011 18:10
An: Jesske, Roland
Cc: [email-masked]
Betreff: Re: [dispatch] Update fo RFC3326 or draft-jesske-dispatch-reason-in-responses approach

Regards,
Mary.

Sorry

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 28 Jan 2011 22:21:12 +0530

Hi Roland,
 
Including Roland in this mail thread...
 
For your requirement, Update of RFC 3398 may solve the issue but update of RFC 3326 is a workaround.
 
Please correct me in case I'm missing something.
 
Thanks
Partha

From: [email-masked] on behalf of Parthasarathi R (partr)
Sent: Thu 1/27/2011 10:36 PM
To: Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [dispatch] Update fo RFC3326 ordraft-jesske-dispatch-reason-in-responses approach

Hi Roland,

 

  

Thanks
Partha

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Jan 2011 11:14:42 -0500

On 1/28/2011 8:11 AM, [email-masked] wrote:
> So seeing from your mail I see that there an UPDATE to RFC3326 would be
> more convenient and my other draft could help to have some reasoning/use
> cases.

Its a very simple draft (which is fine).

I do find an inconsistency. The overview states:

    This document specifies and formally permits the use of the
    Reason header field in SIP responses to carry Q.850 [Q.850]reason
    codes for this and other purposes.

But the actual normative changes permit *any* sort of reason codes in 
responses.

This could be especially confusing if a sip reason code is included in a 
sip response.

Also, this says nothing about what it *means* to have a reason code in a 
response, while 3326 does say a bit about what it means to put a Reason 
in a request. In the case of Q.850 reasons its fairly obvious, at least 
coming from a Q.850 gateway.

The simple answer here would be to exclude the use of SIP Reasons in 
responses. Else there had better be text on when it is appropriate. (And 
I can't think of any.)

	Thanks,
	Paul

>     ------------------------------------------------------------------------
>     *Von:* Mary Barnes [mailto:[email-masked]]
>     *Gesendet:* Donnerstag, 27. Januar 2011 18:10
>     *An:* Jesske, Roland
>     *Cc:* [email-masked]
>     *Betreff:* Re: [dispatch] Update fo RFC3326 or
>     So, the question isn't whether to progress the draft per se but
>     whether the implication of the functionality you describe is a
>     normative change RFC 3326 (i.e., UPDATES) or whether an
>     informational draft is sufficient. I would posit that if this work
>     is progressed as informational, then it should be restricted to
>     describing the use of SIP responses to carry the Q.850 reason codes
>     and drop the the "other purposes". And, you need to remove the
>     normative RFC 2119 language. In other words, if folks do not believe
>     an update to RFC 3326 is necessary then the drafts needs to be
>     revised to limit the scope and be quite clear that it is informational.
>
>     Regards,
>     Mary.
>
>          > Von: [email-masked] <mailto:[email-masked]>
>          > [mailto:[email-masked]
>         <mailto:[email-masked]>] Im Auftrag von Jesske, Roland
>          > An: [email-masked] <mailto:[email-masked]>
>          > [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

---

From: Shida Schubert <[email-masked]>
Date: Sat, 29 Jan 2011 16:58:03 +0900

+1 for solution 2 as well. 

 Shida

---

From: <[email-masked]>
Date: Mon, 31 Jan 2011 11:53:21 +0100

Hi Paul,
Thank you for the hint.
Yes I agree that it would be a little seldom if a SIP reason code would be included within a SIP Response.
So I tried to change the wording like:

Section 3. New 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, if it contains a Q.850 Cause Code,  except the 100 trying response.

Section 4. New Text:

The Reason header field containing a Q.850 Cause Code MAY appear in any request within a dialog, in any CANCEL request. The appearance of the Reason header is applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x and 199

So I hope now the document is more consistent.

Best Regards

Roland

> [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
> Gesendet: Freitag, 28. Januar 2011 17:15
> An: [email-masked]
> Betreff: Re: [dispatch] Update fo RFC3326 or
> > until now it looked for me it is the decision of people
> which way they
> > want to go.
> <mailto:[email-masked]>
> >          > a couple of days we discussed how to proceed
> with the reason
> >          > in responses.
> >          >
> >          > approach should we take. (Mary asked this
> question also on
> >         Monday)
> >          >

---

From: <[email-masked]>
Date: Mon, 31 Jan 2011 14:20:26 +0100

Hi Partha,
A UPDATE to RFC3326 will reflect that what is already implemented all over the world while a UPDATE to RFC 3398 will never succeed due to the fact that the Q.850 CV are very different to SIP Responses.

There are groups of Q.850 Causes that are mapped to the same SIP Response due to the fact that only one fit to such a Response. E.G Response 503 is very often used for a couple of Q.850 causes. But the CV itself causes within ISUP different reactions (e.G special Tones or Announcements).

And as the reactions showed there is enough support for a further progress to allow the Reason header (containing Q.850 Causes) within responses.

Best Regards

Roland
  _____

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Parthasarathi R (partr)
Gesendet: Freitag, 28. Januar 2011 17:51
An: Paul Kyzivat (pkyzivat); [email-masked]; Jesske, Roland
Betreff: Re: [dispatch] Update fo RFC3326 ordraft-jesske-dispatch-reason-in-responses approach

Hi Roland,

Thanks
Partha

  _____

Hi Roland,

Thanks
Partha

  _____

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Jan 2011 10:12:50 -0500

> I don't follow your argument that a blanket RFC allowing Reason in any response, or a large set of responses, would mean an update to RFC 3261. However, if the conclusion is that updating RFC 3326…

John,

Yeah, you are probably right that its not an update to 3261. Its an 
update to 3326.

Ultimately no matter which way it is specified, it has potential impact 
on all those who handle any of the affected response codes, and it 
affects all those who are interested in Reason codes. The trick is 
publishing it in such a way that all those impacted will discover that.

RFC 3326 was an extension to 3261. However specified, this is either an 
extension to 3326 or another extension to 3261. From a practical 
perspective, it might be better to view this as an independent extension 
to 3261 that happens to reuse the same Header that 3326 did, but in a 
different context. (ISTM that using Reason in responses will be somewhat 
different than using it in requests.)

The trick is finding the best way that potential implementers, or those 
encountering the header during interop testing, will be able to discover 
the spec that they need to implement. For that, IANA is probably key. It 
should end up that the IANA registry entry for the Reason header should 
cross reference this new document that specifies use of Reason in 
responses. Any approach that accomplishes that is probably ok. (But see 
my other message about SIP response codes in responses.)

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 31 Jan 2011 16:53:50 +0100

I had a look at this and came to the conclusion that there were two ways of doing it.

1)	Update the relevant sentences in RFC 3226.

2)	Update every response code defining document to indicate the applicability to reason in order to conform to the existing requirements of RFC 3226.

I'm sure the second of these would confuse the hell out of most readers, so it seems simplest to update RFC 3226. This essentially changes the rules for response usages, rather than bending everything to follow the rules.

I believe this is what Roland is proposing.

Keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 31 January 2011 15:13
To: Elwell, John
Cc: [email-masked]
Subject: Re: [dispatch] Update on draft-jesske-dispatch-reason-in-responses

John,

	Thanks,
	Paul