Re: New version (-04) of draft-ietf-sip-199

Hi John, 

>>"If the received initial request contains an 199 option tag, the UAS
>>   SHOULD NOT send a 199 response for a dialog on which it intends to
>>    send a final response, unless it e.g. has been configured to do so
>>    due to lack of 199 support by forking proxies or other
intermediate
>>    SIP entities."
> 
>I doubt that a UAS would implement a new configurable 
>parameter just so that it can reduce resource consumption at 
>the UAC when the forking proxy has not bothered to implement 
>199. It is far easier for the UAS never to send 199. So is it 
>really worth specifying this option?

It is probably true that a SIP phone type of UAS would not implement a
new configurable parameter for this.

However, the UAS could be a "network entity", e.g. an application
server, or a B2BUA, and in such cases the operator may have a
configurable parameter. So, I think we should allow it.


>>"When a forking proxy receives a non-2xx final response which
>>terminates one or more (if forking has occured downstream a final
>>response received by the forking proxy MAY terminate multiple early
>>dialogs), and the proxy does not intend to forward the 
>>final response immedialetly (due to the rules for a forking proxy),
and 
>>the UAC has indicated support of the 199 response code, the proxy 
>>SHOULD generate and send a 199 response upstream for the early dialog
on which the
>>non-2xx final response was received, unless the proxy has 
>>previously recieved and forwarded a 199 response for the dialog."
>
>Wow! We really must shorten this sentence. In particular I 
>don't like including a second normative sentence in 
>parentheses within the main sentence.

I can try to think of more simple wording. 

And, text suggestions are of course always welcome :)


>>"If the forking proxy has stored the Contact and Record-Route headers
>>for the early dialogs, it SHALL insert the headers in the 199
>>responses."
>Which Contact and Record-Route header fields? Presumably the 
>ones received from the UAS (as opposed to the UAC), but it 
>doesn't make this clear.

Yes, that should be clarified.

>Also, if there is no compulsion to store these header fields, why make
it mandatory to transmit 
>them if they have been stored?

I was requested to add text about the possibility to store the header
fields and included them in the response. I see no harm in doing so,
since storing the parameters is optional anyway.

Regards,

Christer





> 	From: [email protected] 
> [mailto:[email protected]] On Behalf Of Christer Holmberg
> 	Sent: 07 January 2009 08:49
> 	To: [email protected]
> 	Subject: [Sip] New version (-04) of draft-ietf-sip-199
> 	
> 	
> 
> 
> 	Hi, 
> 
> 	Based on comments and discussions, I've submitted a new 
> version of the 199 draft. 
> 
> 	The currently remaining to-do is to add text to the 
> security chapter. 
> 
> 	The draft can also be found at: 
> 
> 	http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-04.txt
> <http://users.piuha.net/cholmber/drafts/draft-ietf-sip-199-04.txt>  
> 
> 	Regards, 
> 
> 	Christer 
> 
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip