If it's a bug in RFC 3261 then maybe the proper thing to do is to issue
an errata? That way this informational doc can either not get into the
matter or reiterate the errata.
Thanks,
Anders
On 5/11/2010 7:54 AM, Paul Kyzivat wrote:
gao.yang2@xxxxxxxxxx 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
