From: "Vijay K. Gurbani" <[EMAIL PROTECTED]> > 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;
I think you are being too literal about the table; the table itself is first described in S5, the opening paragraph of which is: "This section is tutorial in nature, and does not specify any normative behavior." Thus, I do not see how one can construe that the existence of the table is mandatory. Furthermore, rfc3261 essentially uses the same information in S18, where it talks about "These connections are indexed by the tuple formed from the address, port, and transport protocol at the far end of the connection." The table in connect- reuse is the same information, albeit in an easy to visualize manner. I really do not see the harm. After thinking about this some more, I'll retract my objection. In principle, I think the problem still stands, but this case is simple enough that no trouble can result. Do note: You introduce the table in section 5, which is marked non-normative. But you refer to the table 16 times in section 8, which is marked normative, and furthermore you don't re-introduce the table or its behavior. Which, unless I've overlooked something again, means that the normative section 8 contains a prerequisite reference to the non-normative section 5. I think you're going to have to adjust that. > > 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? Sure ... this is the IETF, right? This protocol specification is supposed to be read by programmers who would know what a Unix- style file descriptor is. In fact, if you go back to rfc2543, it actually had actual *C code* for demonstrating how to write a forking proxy (which I must say was great for understanding forking mechanics when I wrote my first forking proxy back in 1998.) Other RFCs also have code and domain-specific nomenclature (see for example drafts and RFCs in PKIX, many of which have ASN, BER, DER and other encodings and cryptographic language pertinent to and rooted in that domain.) I doubt harm can come from it, but I don't see the Posix programming model as being one of the background domains for understanding SIP. Suppose, for example, that one's SIP stack was written in Java... 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
