[EMAIL PROTECTED] wrote:
vkg> By "exactly as previously", do you mean handled as TLS?
No, as described in RFC 3261.
OK; I will wordsmith some text to refer to rfc3261.
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.
Not specifying behavior explicitly leads to versions of the "implement
to example" problem that has plagued SIP since the early days.
"Implement to example" in SIP has resulted because either there
are many ways to do the same thing, or because due to insufficient
guidance, a developer latches on to an example and considers that
the canonical form for doing something in SIP.
I don't see how presenting information in a tabular format leads
to implementation by example. There is ample additional text
that explicitly specifies the behavior.
> 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.)
> 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.)
OK; I think it may be good to separate the notion of persistent
connection (as suggested by Hadriel) and connection reuse. The
former is when a client uses the same connection to send multiple
requests in the downstream direction, and the latter is when the
downstream entity can use the same connection to send new requests
upstream. I will add this notion in the revision.
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: [EMAIL PROTECTED],bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
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
