Subject: [sipcore] Reason as a parameter rather than an escaped header

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 11 Nov 2010 04:09:02 -0500

First, I don't like the term "an escaped header".  The escaping
process is not central, what is central is that the "header" (per 3261
BNF terminology) is "added to" or "inserted into" the URI.

From: Paul Kyzivat [[email-masked]]
> On 11/7/2010 6:39 PM, Mary Barnes wrote:
> > I think there is still some confusion here - the Reason is NOT a URI
> > parameter. It is a SIP header field that is escaped in the URI for
> > compactness.
> 
> I don't think there is any real confusion. Its just that the terminology
> is awkward. We have parameters to headers, and we have headers that are
> parameters to URIs.

The BNF in RFC 3261 calls these things "headers":

    SIP-URI          =  "sip:" [ userinfo ] hostport
			uri-parameters [ headers ]
    headers         =  "?" header *( "&" header )
    header          =  hname "=" hvalue

In our organization, we call them "header parameters", contrasted to
"URI parameters" ("uri-parameters" per 3261) and "field parameters"
(which has no proper name in 3261, but its syntax is "generic-param").
These phrases are used in the prose of 3261 with these meanings
(usually).

> > In earlier versions, we had a separate parameter in the
> > SIP History-Info header for Reason, but Rohan suggested to just escape
> > the existing Reason header in the URI so as not to redefine Reason
> > parameters.
> 
> I even remember him making that suggestion. Too bad he isn't around so
> we can wring his neck. I thought it was a hack at the time, but didn't
> then realize how much trouble it would cause.

Certainly, doing so is conceptually incorrect, as the reason is a
property of the request-URI that was used, not a portion of that
request-URI.  Fortunately, no operational failure can result, as the
request-URI of a request cannot contain header parameters.

But it looks like we need to continue this hack for compatibility.  So let us:
- publicly state this is a hack
- not repeat the mistake in other cases

> > The Reason header is intended to tag the Reason why the hi-targeted-to
> > URI was retargeted and thus it goes with the "old" hi-entry versus the
> > "new" one.
> 
> Just stating it that was exposes the problem.
> The intent of the Reason header is specified in RFC3326.
> Any use that isn't consistent with that is an abuse.
> Its intended to indicate why a *request* is being sent.

Yes, but it quickly mutated into a carrier in responses to provide
additional information as to why the response was generated.
Consider:

   draft-jesske-dispatch-reason-in-responses-02

   Abstract

   Although the use of the Reason header field in responses is
   considered in RFC3326, doing so is not specified for any existing
   response code.  Nonetheless, the Reason header field has been widely
   used in responses to carry Q.850 reason codes for failure responses
   to INVITEs that have been gatewayed to PSTN systems.  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.

> > Also, note that we cannot change this now even if it were the right
> > thing to do due to backwards compatibility.
> 
> So then we allow it continue to metastasize, e.g. by defining new Reason
> values that aren't ever expected to be used in requests, and that
> wouldn't make any sense if they were?

That seems likely.  It's probably a good thing.  It's a bit sketchy to use
the same header to describe why a request was generated and also why
a response was generated, but it's not going to cause confusion.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Nov 2010 23:00:02 +0800

inline

> - not repeat the mistake in other cases

yep

>     draft-jesske-dispatch-reason-in-responses-02

1 - quickly? The Reason header is old.
2 - did I miss something? what is the status of the jesske draft?
     isn't it still just an individual draft?

> a response was generated, but it's not going to cause confusion.

I disagree its a good thing.

If we need new response codes we can define them, so we shouldn't in 
general need new response codes to clarify response codes.

Perhaps the Q.850 stuff is a special case since we are there relating 
things from a different and independent namespace. Even then its a bit dicy.

But my point wasn't reasons for requests vs. reasons for responses. It 
was about reasons for requests vs. reasons for H-I entries. And IIUC the 
reasons in Marianne's draft are *not* reasons for responses. They are 
reasons for retargeting, generally without there having been any 
response. They are indeed a reason for a request. And it is a reason for 
the request with the new target, not the reason for the request with the 
old target.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 23 Nov 2010 14:26:37 -0500

>      isn't it still just an individual draft?

Yes, you missed something, and so did everybody else.  As turned up in
the discussion of the Jesske draft during one IETF meeting, just about
everybody assumes that Reason can be used in responses, and appears to
have been assuming that for many years.  The Jesske draft in to
officially permit what everybody has been doing all along.

> the request with the new target, not the reason for the request with the

How you feel about this depends on how you assume the system is
architected.  In my case, I expect *all* redirections to be due to 302
responses received by the proxy from a redirect server.  So I expect
(perhaps incorrectly) to see H-I entries like this:

History-Info:  <sip:original-address \
	           ?Reason=SIP;cause=302, \
		           application;cause=2;text="Freephone">;index=1,
	       <sip:new>;index=1.1
[with considerable abuse of the escaping rules]

That is, the "application" value carries more information about why
the "SIP" value (302) was generated.

But I don't know if others think that Reason will be commonly used in
this way.

Dale

---

From: Mary Barnes <[email-masked]>
Date: Tue, 23 Nov 2010 14:00:01 -0600

I think we are somewhat ratholing here.  A few responses inline below [MB].

On Thu, Nov 11, 2010 at 9:00 AM, Paul Kyzivat <[email-masked]> wrote:

> But my point wasn't reasons for requests vs. reasons for responses. It was
> about reasons for requests vs. reasons for H-I entries. And IIUC the reasons
> in Marianne's draft are *not* reasons for responses. They are reasons for
> retargeting, generally without there having been any response. They are
> indeed a reason for a request. And it is a reason for the request with the
> new target, not the reason for the request with the old target.
>
The intent of the Reason in the HI entries is to capture the reason a
request was retargeted.  The current normative text is the Reason (escaped
header, header field, whatever) in the HI-entry is populated based on SIP
Response codes and any other Reason header (e.g., Q.850) that might be
associated with the request.  The Reason is included in the hi-entry with
the hi-targeted-to-uri that was retargeted (i.e., the old) versus the
hi-targeted-to-uri in the hi-entry to which the Request is being sent.  We
should not change this due to backwards compatibility AND I think any new
Reason values that we want to add to the hi-entries need to be added
consistently.

Thus IF there is agreement to add new Reason header field values for
applications, then if those are used to populate the hi-entry, they should
also be interpreted in the hi-entries to correspond to the
hi-targeted-to-uri that was retargeted (i.e., the old URI that is lost)
based on a decision that the request be associated with a specific
application RATHER than the Reason being the application associated with the
hi-entry with the hi-targeted-to-uri to which the request is being sent
(i.e, the new URI).

I would suggest that the best way forward is that we keep the current text
as is and note that any additional Reason headers that are defined in the
future MUST be interpreted in the same manner.  However, I do NOT think we
should hold up 4244bis until we get full agreement on adding new Reason
header values for applications as I firmly believe it is orthogonal - it can
work based upon the current normative approach and interpretation of the
Reason in the hi-entries.  We can debate till the end of time (or the end of
SIPCORE WG as we did with other broken things in SIP) that this wasn't the
right approach, but it is what it is and I think it's time to move forward.

Regards,
Mary.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Nov 2010 19:06:37 -0500

> I think we are somewhat ratholing here.  A few responses inline below [MB].

Yes, I agree on that.

> request was retargeted.  The current normative text is the Reason
> (escaped header, header field, whatever) in the HI-entry is populated
> based on SIP Response codes and any other Reason header (e.g., Q.850)
> that might be associated with the request.  The Reason is included in
> the hi-entry with the hi-targeted-to-uri that was retargeted (i.e., the
> old) versus the hi-targeted-to-uri in the hi-entry to which the Request
> is being sent.  We should not change this due to backwards compatibility
> AND I think any new Reason values that we want to add to the hi-entries
> need to be added consistently.

> applications, then if those are used to populate the hi-entry, they
> should also be interpreted in the hi-entries to correspond to the
> application RATHER than the Reason being the application associated with
> the hi-entry with the hi-targeted-to-uri to which the request is being
> sent (i.e, the new URI).

In the interests of making progress rather than rat hole'ing, I already 
agreed (reluctantly) to acknowledge that the Reason headers in H-I 
entries need to continue to be assigned to the entries they have been, 
even though IMO this is nonsensical. We established that the URIs in H-I 
entries come from R-URIs that have no embedded headers, so that the 
embedded header in the H-I entry is only there as a result of explicit 
addition during the construction of the H-I entry. We just have to 
consider that the semantics of its presence there are unique.

I'm no longer arguing that point.

But my remaining concern is about the rules in 4244bis regarding how and 
when Reason headers are included in the H-I entries. It still seems to 
me that the text only talks about including them due to a response 
having been received. Where is the language that discusses adding a 
reason when retargeting is performed for some reason unrelated to a 
response?

While I think one can argue that a server doing such retargeting can 
imagine having sent the request to a virtual redirect server and then 
processing the response from it, ISTM that would then call for adding 
H-I entries for those steps.

> I would suggest that the best way forward is that we keep the current
> text as is and note that any additional Reason headers that are defined
> in the future MUST be interpreted in the same manner.  However, I do NOT
> think we should hold up 4244bis until we get full agreement on adding
> new Reason header values for applications as I firmly believe it is
> orthogonal - it can work based upon the current normative approach and
> interpretation of the Reason in the hi-entries.  We can debate till the
> end of time (or the end of SIPCORE WG as we did with other broken things
> in SIP) that this wasn't the right approach, but it is what it is and I
> think it's time to move forward.

I agree that 4244bis should not be held up because of the new reason 
values draft(s?).

At this point I would just like some clarity whether the *way* reasons 
are used in the examples in 
draft-mohali-sipcore-reason-extension-application-00 - reasons without 
responses - is thought to be *valid* in the context of 4244bis. If the 
answer is NO, then I'll shut up, and let Marianne or somebody else from 
3gpp complain if they think it should be.

If the answer is YES - that usage is considered valid according to 
4244bis, then I still want to know why, and perhaps see some additional 
text to make it clear.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Nov 2010 21:27:19 +0100

Hi,

>4244bis, then I still want to know why, and perhaps see some additional

I think we should ask ourselves: assuming we allowed to do what Marianne is proposing, would anything break?

Does anyone really care whether a H-I entry was inserted based on a "real" or "virtual" response? Aren't people more interested in the actual reason value?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Nov 2010 17:36:32 -0500

> Does anyone really care whether a H-I entry was inserted based on a "real" or "virtual" response? Aren't people more interested in the actual reason value?

I don't currently see a problem with permitting this (though I'm 
interested to hear if somebody else sees an issue).

But IMO the current text doesn't suggest to me that this is valid.
So if the desire is for it to be valid it would be good to have some 
text that makes it so.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Nov 2010 07:48:22 +0100

Hi, 

>>I think we should ask ourselves: assuming we allowed to do 
>>what Marianne is proposing, would anything break?
>>
>>Does anyone really care whether a H-I entry was inserted 
>>based on a "real" or "virtual" response? Aren't people more 
>>interested in the actual reason value?
> 
>I don't currently see a problem with permitting this (though 
>I'm interested to hear if somebody else sees an issue).
> 
>So if the desire is for it to be valid it would be good to 
>have some text that makes it so.

I agree. We would need to add some text.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 25 Nov 2010 06:57:01 -0500

> H-I entries for those steps.

Right, that's the main piece to figure out first.  We already agreed that 4244bis tells proxies to create H-I entries for internal retargeting decisions.  What's not clear is what internal H-I entries have to be created, and whether the embedded Reason header value of the *SIP* type can be used for such cases.

For example, suppose Alice called Bob, and proxy-1 internally diverts it to Charlie because it knows Bob is busy, *without* having to send the INVITE to Bob and getting a 486 response.

Is it legit for the H-I look like this:
History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D486>;index=1
History-Info: <sip:[email-masked]>;index=1.1;mp=1
History-Info: <sip:[email-masked]>;index=1.1.1;rc=1.1

Or does it have to look like this:
History-Info: <sip:[email-masked]>;index=1
History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D486>;index=1.1
History-Info: <sip:[email-masked]>;index=1.2;mp=1
History-Info: <sip:[email-masked]>;index=1.2.1;rc=1.2

Or does it have to do something like this:
History-Info: <sip:[email-masked]?Reason=Internal%3Bcause%3D486>;index=1
History-Info: <sip:[email-masked]>;index=1.1;mp=1
History-Info: <sip:[email-masked]>;index=1.1.1;rc=1.1

-hadriel

---

From: <[email-masked]>
Date: Thu, 25 Nov 2010 23:33:25 +0100

Hi,

I agree that draft-mohali-sipcore-reason-extension-application could live independently of 4244bis, except for the section "Reason in the History-Info header" that should still allow wat is proposed in draft-reason.

Note that RFC4244 is compatible with the draft-reason proposal: As work on 4244bis was in progress, we based the draft on the following text from RFC4244: "For retargets as a result of timeouts or internal events, a Reason MAY be associated with the hi-targeted-to-uri that has been retargeted."

Unfortunately, this sentence disappeared and only the last sentence about timeout suggests to insert a Reason for an internal process.
 
If there is no objection, we could put this text back in 4244bis to keep explicit the ability to insert the Reason header field in a H-I entry for *internal* reasons (with a MAY).    

Regards,
Marianne 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Christer Holmberg
> Envoyé : jeudi 25 novembre 2010 07:48
> À : Paul Kyzivat
> Cc : Worley, Dale R (Dale); [email-masked]
> Objet : Re: [sipcore] Reason as a parameter rather than an 
> escaped header
> 
> 
> Hi, 
> 
> >>I think we should ask ourselves: assuming we allowed to do what 
> >>Marianne is proposing, would anything break?
> >>
> >>Does anyone really care whether a H-I entry was inserted based on a 
> >>"real" or "virtual" response? Aren't people more interested in the 
> >>actual reason value?
> > 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: <[email-masked]>
Date: Thu, 25 Nov 2010 23:48:19 +0100

Hi,

My adding [MM]

Marianne

> [mailto:[email-masked]] De la part de Hadriel Kaplan
> Envoyé : jeudi 25 novembre 2010 12:57
> À : Paul Kyzivat
> > But my remaining concern is about the rules in 4244bis 
> regarding how 
> > and when Reason headers are included in the H-I entries. It still 
> > seems to me that the text only talks about including them due to a 
> > response having been received. Where is the language that discusses 
> > adding a reason when retargeting is performed for some reason 
> > unrelated to a response?
> > 
> Right, that's the main piece to figure out first.  We already 
> agreed that 4244bis tells proxies to create H-I entries for 
> internal retargeting decisions.  What's not clear is what 
> internal H-I entries have to be created, and whether the 
> embedded Reason header value of the *SIP* type can be used 
> for such cases.
> 
> For example, suppose Alice called Bob, and proxy-1 internally 
> diverts it to Charlie because it knows Bob is busy, *without* 
> having to send the INVITE to Bob and getting a 486 response.
> 
> History-Info: 
> <sip:[email-masked]?Reason=Internal%3Bcause%3D486>;index=1
[MM] Or (as per 3GPP CDIV 24.604 for call forwarding busy)
History-Info: <sip:[email-masked]>;index=1
History-Info: <sip:[email-masked];cause=486>;index=1.1;mp=1
History-Info: <sip:[email-masked]>;index=1.1.1;rc=1.1

---

From: <[email-masked]>
Date: Fri, 26 Nov 2010 13:06:40 +0100

Only to indicate that draft-jesske-dispatch-reason-in-responses-02 is in a queue where I wait for an indication how to proceed. If it should be progressed as an individual draft or as an WID in DISPATCH (or perhaps in SIPCORE).

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked]
> [mailto:[email-masked]] Im Auftrag von Worley, Dale R (Dale)
> Gesendet: Dienstag, 23. November 2010 20:27
> An: Paul Kyzivat
> Cc: [email-masked]
> Betreff: Re: [sipcore] Reason as a parameter rather than an
> escaped header
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 28 Nov 2010 21:20:28 -0500

I'm not especially particular about which of the various patterns of H-I 
entries are permitted - could be one or more of them, with discretion 
about what to include. (Though there could be merit in permitting 
omission of extra "virtual" entries that add no value.)

But whatever it is, the draft should say *something* that is sufficient 
to determine if the usage chosen is valid or not.

	Thanks,
	Paul

On 11/25/2010 5:48 PM, [email-masked] wrote:
>> History-Info:<sip:[email-masked]?Reason=SIP%3Bcause%3D486>;index=1
>> History-Info:<sip:[email-masked]>;index=1.1;mp=1
>> History-Info:<sip:[email-masked]>;index=1.1.1;rc=1.1
>>
>> History-Info:<sip:[email-masked]>;index=1
>> History-Info:<sip:[email-masked]?Reason=SIP%3Bcause%3D486>;index=1.1
>> History-Info:<sip:[email-masked]>;index=1.2;mp=1
>> History-Info:<sip:[email-masked]>;index=1.2.1;rc=1.2
>>
>> History-Info:<sip:[email-masked]>;index=1.1;mp=1
>> History-Info:<sip:[email-masked]>;index=1.1.1;rc=1.1
>>
> History-Info:<sip:[email-masked]>;index=1
> History-Info:<sip:[email-masked];cause=486>;index=1.1;mp=1
> History-Info:<sip:[email-masked]>;index=1.1.1;rc=1.1
>
>> -hadriel
>>