Hi Robert, In this reply I will try to address all issues except the ones related to proxies-sending-reliably-199, which is dealt with in another thread.
>1) The header says intended status is Informational? You mean PS, right? I guess so. >3) In section 6 you talk of a non-2xx final response terminating one or more early > dialogs. Can you give me an example scenario where "more" comes into play? > (preferably add one to the text)? I'm having a hard time seeing how this ever more > than one. What I mean to say is that when the UAC receives a final response for an early dialog it normally releases all other early dialogs (the UAC should of course still be ready to accept 200 OK responses for other dialogs). >4) Section 6 says the proxy MUST send a 199 when it receives on of these non-2xx > final responses. Why is this MUST and not MAY? > There's no Require header here. We can have motivational text saying why > proxies might really want to, but saying MUST or even SHOULD seems wrong > from a protocol requirement point of view. The idea is that if the proxy supports the 199, it must send it. >5) With respect to that same requirement - it looks right now like you're requiring > the proxy to 199 this to-tag even if the UAS that generated it already did and the > proxy already forwarded that 199 even. I can add text saying that if the proxy is aware that a 199 has already been sent for a particular dialog, it shall not send a 199. >6) Section 6 paragraph one's "MAY release resources" might be misconstrued to > imply releasing the transaction state, which is NOT what you mean. I'll propose > text to help try to avoid that later. I guess we can add text saying that the transaction state must be maintained as defined in 3261. Feel free to propose text :) >8) The last paragraph of section 7 uses MUST NOT and MUST where it really > should be using does not and is. This paragraph describes things that are > rather than mandate behavior. I'll have a look. >9) Section 8 second open issue: We agreed that we were not addressing HERFP > with this draft. If we are going to open this mechanism up to something that > even _partially_ starts to address HERFP (by, as proposed, including the > non-2xx response that caused the 199), then we need to stop work on this > draft and go work on HERFP. In other words, my vode for the answer to this > open issue is "NO". Based on the agreement in Dublin I intend to remove it. >10) Section 8 first open issue: This looks, at best, to be an optimization of an > optimization. Considered in the light of having multiple proxies on the > response path that would have to do extra parsing work because of this > optimization, I don't think we should consider it further. Ok. >11) I can't follow the second paragraph of section 9 at all. Can you rephrase it? > Once I know what its trying to say, I'll propose alternate text. What it is supposed to say is that you cannot send a 199 if you are required (by the offer/answer rules) to include SDP. >13) The security considerations section is TBD. > There's a lot to talk through here. For instance, I can spoof 199s to affect how a call > is ultimately answered in ways that are different (from the endpoints visibility into > what happened point-of-view) from cancels/byes or even other response manipulation. I agree we need to deal with the security considerations. I was hoping we could get rid of some of the open issues first. Thank you very much for your comments! 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
