RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

["Michael Hammer \(mhammer\)" <[e-mail]>]

John,

Independent of the current argument, the point you make suggests that
RFC 3326 needs to be revised.  When you talk about the explicitly
allowed requirement, where would that be found?  

In RFC 32361 there is a table that says what header can go in what
message or response including 3xx responses.  Other RFCs, when adding a
new header replicate that table and provide this information.  What your
assertion below contends vis-a-vis 302 and Reason header, is that either
RFC 3261 (because that is where 302 is defined) or 3326 (because that is
where Reason header is defined) gets updated to provide that table.
Having an additional RFC provide that table providing permissions for
existing headers and methods/responses would be a hack.

Am I misreading this?

Mike

> -----Original Message-----
> From: Elwell, John [mailto:[e-mail]] 
> Sent: Tuesday, October 18, 2005 2:32 AM
> To: Francois Audet; Paul Kyzivat (pkyzivat)
> Cc: Michael Hammer (mhammer); sipping
> Subject: RE: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> Francois, Paul,
> 
> I don't think this particular branch of this thread is going 
> anywhere. The history behind this (no pun intended) is that 
> the redirection-reason draft proposed the use of a Reason 
> header within a 3xx response to indicate the real reason 
> (since it is forced to use an artificial 3xx response in 
> order to signal that it is redirecting). This isn't 
> explicitly specified by RFC 3326, which states in section 1: 
> "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". Therefore it 
> requires an RFC explicitly to allow the Response header in a 
> 3xx response. We don't have it at present, but it could be 
> achieved. The History-Info draft anticipates this by making 
> provision to make use of a Reason header in a 3xx for 
> populating the History-Info header.
> 
> However, one of the concerns with the redirection-reason 
> draft was that it required upgraded UACs in order for it to 
> function as intended. This was one of the main motivations 
> for the proposal in the service-retargeting draft, which 
> captures relevant information in the URI to ensure automatic 
> handling at the UAC.
> 
> John
> 
> 
> > -----Original Message-----
> > From: Francois Audet [mailto:[e-mail]]
> > Sent: 18 October 2005 02:52
> > To: Paul Kyzivat
> > Cc: Michael Hammer (mhammer); sipping; Elwell, John
> > Subject: RE: [Sipping] Re: 
> > draft-elwell-sipping-service-retargeting-00.txt
> > 
> > 486 is a response. In this particular example, it is a response 
> > without a corresponding request.
> > 
> > I don't know how more dubious it can be. I mean, sending "implied"
> > responses
> > to a request that never happened to me seems very dubious. 
> Maybe it is 
> > just me...
> > 
> > Let's say we used Q.850, or even a new space for a response 
> if it is 
> > less dubious.
> > Or let's say everybody thinks that it is not dubious in the first 
> > place.
> > I am
> > willing to bet that it would be completely unimplementable with 
> > equipment today, and in the near future (say, 5 years). I do not 
> > imagine that anybody would look at some arcane ambigous 
> Reason header 
> > embedded deeply with escape characters into an OPTIONAL NEW 
> > History-Info header, and make routing decisions based on it.
> > 
> > To me, shooting directly at the proper URI is always going 
> to be less 
> > prone to errors than having the application look at parameters that 
> > where not meant for routing, and that are almost never 
> implemented...
> > 
> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:[e-mail]]
> > > Sent: Monday, October 17, 2005 17:08
> > > To: Audet, Francois [SC100:9T51:EXCH]
> > > Cc: Michael Hammer (mhammer); sipping; Elwell, John
> > > Subject: Re: [Sipping] Re: 
> > > draft-elwell-sipping-service-retargeting-00.txt
> > > 
> > > 
> > > 
> > > 
> > > Francois Audet wrote:
> > > > In the case where the far end actually sent a 486, it 
> makes sense.
> > > > 
> > > > In the case where the far end did NOT send a 486, i.e.,
> > > that forwards
> > > > the call itself with a 302, it seems highly dubious to me
> > > to insert a
> > > > "fake" 486 inside a Reason header.
> > > 
> > > Doesn't seem so dubious to me. If I am a UA, and I return a 302
> > > *because* I am currently busy, then it makes sense to me to
> > include a
> > > 486 reason. I don't find anything in 3326 that says sip 
> reason codes 
> > > can only be used when a response containing that value 
> was received.
> > > 
> > > It is however a matter of judgement to decide when any particular 
> > > reason value should be used.
> > > 
> > > I guess the UA could instead choose to use a Q.850 reason
> > code, if it
> > > preferred.
> > > 
> > > The point is that we are not stuck with 302 as the reason
> > code when a
> > > 302 is returned. If something better is known, that can 
> be expressed 
> > > as a reason code, it can be returned. If nothing better is known, 
> > > then we are out of luck in any case.
> > > 
> > > 	Paul
> > > 
> > > 
> > 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP