Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

["Mary Barnes" <[e-mail]>]

Hi Roland,

I think DISPATCH remains the appropriate place for these discussions.  If we did agree specific changes to RFC 3326, that work would not fall under the charter of SIPCORE (as it's currently scoped as I understand it).  

It's not clear to me that this fits the scope of BLISS in that the focus of this document is on the clarifications to RFC 3326 to support certain services/environments.  It's not under the purview of BLISS to make SIP protocol changes.  [I will note that the BLISS charter needs to be updated to reflect how it does interface with SIPCORE and DISPATCH, rather than SIP and SIPPING as it's currently stated.]  I do see that more details of services that would need this reason header might fall into the BLISS WG charter.

My suggestion is that you update the document to incorporate the conclusions of this discussion ( the doc is currently expired) - you'll have to wait for the document submissions to be opened again on July 27th.  In my view, the crux of a work item is whether you need a true update to RFC 3326 or whether you are documenting clarifications  - similar to the sip-offeranswer document in SIPPING.  

Regards,
Mary. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Friday, July 17, 2009 1:33 AM
To: [e-mail]; Audet, Francois (SC100:3055); Worley, Dale (BL60:9D30)
Cc: [e-mail]; [e-mail]
Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

Hi,
With regard to Keith's answer I see that the draft is needed.
But where should this be done?

BLISS, DISPATCH or SIPCORE?

We have now the discussion within DISPATCH due to the fact that the draft was issued for the sipping group.

The issue shall solve interoperability problems with the PSTN where Q.850 causes shall be transferred through SIP.
An other used case is where applications within SIP networks could interpret the Reason header to put an announcement towards a user. This is important within Hybrid networks where SIP and ISUP runs in parallel.

Seen from this point of view the work should be done within BLISS to solve this interoperability problem.

RFC3326 was done within SIP and the draft could be seen as an extension to this RFC so that could be a reason to do this within SIPCORE.

Or the discussion takes place within DISPATCH and the draft was brought to SIPPING.

So how to proceed?

BR

Roland

-----Ursprüngliche Nachricht-----
Von: DRAGE, Keith (Keith) [mailto:[e-mail]]
Gesendet: Donnerstag, 16. Juli 2009 20:30
An: Francois Audet; Dale Worley
Cc: [e-mail]; Jesske, Roland
Betreff: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

If by "the spec" you are referring to the original Reason header RFC 3326, then yes, it did not preclude it, but specifically indicated that any usage had to be documented further.

   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.

There are no RFCs currently specifying the use with any status code.

Note also that the rest of the text in the document is specifically about its use in requests.

If you go back, you will remember that Reason header was being addressed originally at two problems. One was the issue of transferring clearing information from elsewhere in a BYE request, the other was the HERFP problem. The latter was the use case that required things in a response, but there was no agreement on the way forward on this part of the problem. Therefore the Reason header draft was cut down only to address the first problem.

I would note that the argument has been made in the past, and indeed is hinted at in RFC 3326, is that in responses, you should use the response code. This is what SIP UAs are designed to understand and deal with on reception. Therefore it has been stated in the past that if one wishes to deliver information to end UAs that is not covered by the existing response codes, then a new status code should be defined. Therefore no general use of Reason headers in responses was given in RFC 3326 for that reason. I did not originate that argument, and maybe the people who gave that argument should speak up, but it is certainly the argument that shaped RFC 3326 the way it is.

There is a case where you need to get information from a SIP UA acting as a gateway to another SIP UA acting as a gateway and in that case the Reason header in a response would be well justified in that case, and that is certainly one of the cases covered by the draft.

regards

Keith

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Francois Audet
> Sent: Thursday, July 16, 2009 6:16 PM
> To: Dale Worley
> Cc: [e-mail]; [e-mail]
> Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04
> 
> Again, the spec is very clear that it IS allowed.
> 
> I believe the wishy-washy text about "status code explicitly allowing 
> it" was meant to exclude responses that were not appropriate, and 
> restricing it to effectively error responses.
> 
> At the time this was written, I believe we were not clear on which 
> codes were supposed to be appropriate or not.
> 
> Seems to me:
> - Any Error response code should be allowed.
> - I don't think 2XX makes sense.
> - 3XX is controversial (as per the email quoted by Roland): 
> seems to me it
>   would be quite useful
> - Provisional is interesting... Sounds like 199 error response to 
> me...
> 
> > -----Original Message-----
> > From: Worley, Dale (BL60:9D30)
> > Sent: Thursday, July 16, 2009 10:09
> > To: Audet, Francois (SC100:3055)
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04
> > 
> > On Thu, 2009-07-16 at 12:48 -0400, Audet, Francois
> (SC100:3055) wrote:
> > > Hi Roland,
> > > 
> > > You use case is very common.  
> > > 
> > > I believe you are incorrect in saying that "reasons are
> > currently not
> > > allowed in responses. Neither conditionally nor allowed".
> > > 
> > > RFC 3326 says in 1.0:
> > >   "[...] 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."
> > > 
> > > To be honest, I believe Q.850 codes are much more common in
> > Responses
> > > than in requests.
> > 
> > Googling
> > 
> >      "sip/2.0" reason "q.850"
> > 
> > turns up numerous examples of SIP responses using the
> Reason header in
> > the forbidden manner.
> > 
> > I'd say that your draft formally allows what people are
> already doing.
> > 
> > Dale
> > 
> > 
> > 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
> 
_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch