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

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: sipcore-bounces@ietf.org
> [mailto:sipcore-bounces@ietf.org] Im Auftrag von Worley, Dale R (Dale)
> Gesendet: Dienstag, 23. November 2010 20:27
> An: Paul Kyzivat
> Cc: sipcore@ietf.org
> Betreff: Re: [sipcore] Reason as a parameter rather than an
> escaped header
>
> From: Paul Kyzivat [pkyzivat@cisco.com]
> > >> 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
> >
> > 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?
>
> 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.
>
> > 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.
>
> 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
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>