Ben,
More inline. And I have pruned out more settled stuff.
Thanks,
Paul
Ben Campbell wrote:
Thanks for the response--comments inline. I removed sections that I
think we are in agreement on.
On Oct 10, 2008, at 3:57 AM, Miki HASEBE wrote:
[...]
This version backs away from "recommending" the "hints" I reference in
item 2 above, and now correctly references the essential correction
draft in item 1. It seems to me that this version steps further back
from recommending specific practices than the previous version--thus I
still wonder why it is a BCP rather than an informational.
I've kept the draft's intended track as it is and related text unchanged,
because it's still undecided whether it is going to be BCP or
Informational.
I'll follow AD's judgment.
Okay, that is reasonable. While the ADs certainly have the final say in
the matter, I would suggest that if the purpose is to describe race
conditions that can occur, this would be an informational. On the other
hand, if the purpose is to suggest that implementors take specific
actions to avoid or mitigate the conditions, then it might be a BCP.
I can still go either way on this, but would like to get it nailed down,
because it influences the language we need to use.
I think I lean toward BCP so that we *can* make real recommendations
between legal alternatives. Even then there are those "hints" where IMO
there is disagreement over what is best. So in those cases there may
continue to be just discussion, without recommendation.
Section 2, first paragraph after Figure 1: "The caller MAY send a
BYE in the Early state, even though this behavior is NOT RECOMMENDED."
It's not clear to me whether this is a new recommendation made by
this draft, or a description of a recommendation in RFC 3261. (I
find this to be true of much of the normative language in this draft.)
The NOT RECOMMENDED part is now changed to lower case, but it is still
not clear to me if this draft is introducing the MAY or simply
reporting on it.
It is "simply reporting". Reason for recommendation is written in the
draft.
Okay. It would be less ambiguous if it said something to the effect of
"...not recommended by RFC 3261".
By the way, this is really bound up with the question about whether this
is a BCP or an informational RFC. If it's just an informational, then I
tend to assume statements like this are merely describing statements in
the relevant specs. If it's a BCP, then I assume the RFC makes
recommendations above and beyond those in the protocol specs, so it
becomes more important to be unambiguous.
See my comment above on this.
Definition of Moratorium State:
It's not clear to me from the description what the "conceptual"
meaning is for the moratorium state? Can you mention why you chose
the term "moratorium"?
No change or response
The reason to select the name of Moratorium is a temporary period to the
arrival at the perfect condition because of cutting
with BYE though this state is in the Confirmed state.
I'm sorry, but I am having trouble understanding that sentence.
The dictionary definition of "moratorium" is a temporary prohibition of
an activity. I understand that in this case, the state is temporary--but
what activity is being prohibited? It would be helpful to have explicit
text on that in the definition in section 2.
I'm not taking a position on this. To me these are just labels. The
connotation has *some* value, but its of necessity limited. If there is
a better alternative then I would be ok with changing it. But I don't
have a better alternative in mind.
[3.1.4, 3rd paragraph (formerly 4th)]
"This example recommends that 200 be sent
instead of 491 because it does not have an influence on the session.
However, a 491 response can also lead to the same outcome, so either
response can be used."
I'm confused--the text just said 419 is recommended, now it says 200
is better, but then again it really doesn't matter?
The conflict with preceding paragraph is fixed (that paragraph was
removed), but I'm still not sure I understand why you recommend 200,
but then go on to say that either response can be used. I'd suggest
either making a stronger recommendation, or removing the
recommendation entirely.
The reason to recommend 200 is that there is no pending offer in this
case.
However, UA should be prepared to see a 491 response because 3261
isn't clear
on whether the sending of the 491 or the 200.
Ah, that makes sense. It would be clearer to say something to the effect
of "However, since a 491 response can also lead to the same outcome, an
implementation should be prepared to accept either response."
[3.1.4] 4th paragraph:
"The UA should not reject or drop the ACK on grounds of the CSeq
number."
Normative?
No change or response
This is not stating anything beyond what is stated unambiguously in 3261.
Its just reiteration.
I think for a reader not intimately familiar with CSeq handling for ACK
may read more into that sentence than you intend. I propose changing the
word "should" to "will". On reflection, I think you could drop the
sentence completely, since the previous sentence already points out that
the CSeq is _supposed_ to match that of the INVITE.
I had to go back to the book on this one and I'm still not sure. The
CSeq must match if there's no branch, so at best this only applies when
there is a branch. In that case the matching rule doesn't call for
matching on the CSeq, but any case when they didn't match would be
illegal usage by the UAC.
So I think maybe I agree its ok not to mention this.
3.2.1, 2nd paragraph:
"shall return 200" Are you saying that 3261 compliant UAs will do
this, or suggesting a new requirement?
No change or response
There is no new requirement. The problem is that 3261 isn't clear on
whether
the sending of the BYE or the receiving of the response to the BYE
terminates
the dialog. I think that RFC3261 allows both a 200 and an error (ex.
481) to
the BYE request. As a BCP I think this is a best practice but one must be
prepared to see a 481 response.
Also what do you mean by "exchange reports about the session" with
simultaneous BYE requests?
Wording is changed, but it is still not clear to me what you mean by a
exchanging reports about a session when it is terminated.
I mean in this sentence that UAs will exchange the information
that the BYE request has been processed properly and
that session has been successfully terminated.
I think the current language is very confusing.
Does the following capture the intent?
"A UA in the Mortal state will return an error response to any request
that normally operates within a dialog, such as re-INVITE, UPDATE, or
REFER. But in this example, the UA returns a 200 OK when it receives the
BYE request while in the Mortal state. This communicates to the sender
that a dialog has been properly terminated. If, for example, the UA
returned a 481 response, the sender would not be able to tell whether
the dialog had been terminated properly, or whether the BYE was
incorrectly sent for a non-existent dialog.
While the 200 OK response is more useful in this scenario, the sender of
the BYE request must be prepared to receive other responses."
I like that. I had already proposed another alternative to Miki:
"UAs in the Mortal state return error responses to the requests that
operate with a dialog or session, such as re-INVITE, UPDATE, and REFER.
However, the recommended best practice is to return a 200 in response to
a BYE received in Mortal state. This regularizes the common case where
caller and callee exchange BYE messages when a session is being
terminated. It is valid because RFC 3261 doesn't state whether a session
ends then a BYE is sent or when the response to it is received. However
the UA sending a BYE must also be prepared to receive a 481 response,
and should not consider that abnormal."
But I think I like yours better.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
