Re: I-D Action:draft-ietf-sipping-sip-offeranswer-13.txt

Paul Kyzivat <[email protected]> Tue, 11 May 2010 10:54:56 -0400
Newsgroups gmane.ietf.sipping
Message-ID <[email protected]>

[email protected] wrote:
> 
> Hi Shinji,
> 
> 
>  > IMO, Paul, Christer and I agree with this NOTE.
>  > And in previous discussions it seems to be agreed.
>  > Therefore, I think this is not a normative change but a BCP text.
> 
> Considering personal feeling or tendency, it is OK. But I just feel in 
> INFORMATIVE text, it is not proper to put conclusion as parts of RFC3262 
> is not correct.

Do we agree that the issue here is the following from section 3 of 3262:

    If a PRACK request is received by the UA core that does not match any
    unacknowledged reliable provisional response, the UAS MUST respond to
    the PRACK with a 481 response.  If the PRACK does match an
    unacknowledged reliable provisional response, it MUST be responded to
    with a 2xx response.  The UAS can be certain at this point that the
    provisional response has been received in order.  It SHOULD cease
    retransmissions of the reliable provisional response, and MUST remove
    it from the list of unacknowledged provisional responses.


Because of the "MUST be responded to with a 2xx response", we would be 
recommending violation by recommending a 488.

I do agree this is a *bug* in in 3262, since there are cases (such as 
authorization failures) where it would be entirely unacceptable to send 
a 2xx response. This case is not *that* bad - it is *possible* to send a 
2xx, though the outcome from doing so is not so good.

I think I agree with Gao here that we must not *advocate* sending 488 
here. We might still note that the 488 might be sent anyway, and what to 
do if it is received.

	Thanks,
	Paul
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP