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

[Paul Kyzivat <[e-mail]>]

John pointed out something that I hadn't realized - that there is need 
of a new RFC to make the use of Reason legal in 3xx. Given the reference 
in H-I I had assumed that was already legal.

So unless somebody wants to do that, we can end this discussion.

	Paul

Francois Audet wrote:
> 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