From: "Vijay K. Gurbani" <[EMAIL PROTECTED]> > Excessive text is spent on the cases of TCP and SCTP without TLS. As > far as I can see, they are to be handled exactly as previously. It > is useful to explain why this must be so, and section 9.3 does so, > but I don't see the need for the page-long section 5.2 and 5.3.
By "exactly as previously", do you mean handled as TLS? No, as described in RFC 3261. > The description focuses on the "alias table", making that particular > implementation quasi-standard. But I don't see the mechanism as > being complex enough to require describing that specific > implementation in order to make the mechanism clear. The intent is not to make the alias table quasi-standard. Rather, it is easier to follow the subsequent discussion based on the information presented in tabular format. In reality, many robust SIP implementations probably already include such a table anyway. So I do not see the harm in the continued use of the metaphor. The problem I see is that the table is not labeled as a mataphor; it is described as if its existence is mandatory. But what the standard will actually prescribe is the *behavior* that is carried out by the example mechanism you are describing; if it is possible to do so without confusion, it is better to explicitly describe the behavior (and especially making clear the allowed variations) than to describe a mechanism and then imply (but not state) "you have to make it act like this". Not specifying behavior explicitly leads to versions of the "implement to example" problem that has plagued SIP since the early days. > The use of "alias descriptor" is unfortunate. To start with, it is > confusing -- initially I mistook it for some sort of identification > of the row of the alias table. But the concept of "descriptor" as > being a small integer identifying a network connection, as well as > the very term "descriptor", are Unix-specific. Anything wrong with that :-) ? In a standard? > Much better would be to use a neutral term like "internal connection > identifier" and to represent the value by something like "XXXX". As a programmer, I find it convenient to refer to the connection identifier as a descriptor. With your permission, I would like to continue using that analogy. As a standards weenie, I would say that the less we incorporate of specific implementations, the better. We are already plagued by programmers who cannot analyze something without visualizing one, specific, concrete example, and as a consequence they do not envision the range of possibilities that the standard admits, leading to all sorts of errors. We should not encourage that. > There is an overall conflating of two concepts as "connection reuse". > One is using one connection to send more than one request from one > sender to one recipient. The second is using one connection to send > requests in both directions. The first concept is already supported > by RFC 3261; the second is what is being enabled by this I-D. But > the I-D implements both actions using one alias table, obfuscating > the distinction and so obfuscating the changes that the I-D is > introducing. So this is an interesting and very relevant comment. You are absolutely right that there are indeed two concepts of connection reuse. However, I do not believe that the draft conflates them. It's using the same word for both, which requires very close reading to figure out which concept is being talked about at which time. (I'm not claiming that *you* don't keep the two ideas straight, but I'm worried about the next 200 readers.) Dale _______________________________________________ Sip mailing list https://www1.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
