>>>>> On Thu, 20 Dec 2001 14:34:24 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> In summary, I'd still support the 03 behavior if we had to choose one.
> However, since the usage of receiving the optional info on TCP sockets
> is relatively a minor issue, I'm okay with leaving it unspecified if
> we cannot reach consensus.
There has been no opinion on this, so I'd like to revise the draft
with making the TCP implication section unspecified.
I'll make the revise version next week. If you have a strong
objection on this decision, please speak up now.
(For those who are interested but forgot the context) here is a brief
summary so far:
We have 3 options on how to get optional information (such as
extension headers) of incoming TCP segments; (a) use recvmsg() +
ancillary data (as defined in rfc2292bis-02 and before), (b) use a
separate getsockopt (as defined in rfc2292bis-03), and (c) not to
specify a particular mechanism.
In the very old discussion, there were two reasons for the option (a):
(1) not to overload the semantics of IPV6_HOPOPTS, IPV6_DSTOPTS, ...
(2) to provide a uniform interface for TCP and others
The reason (1) is actually not essential to the option (a). This can
be achieved by separating IPV6_xxx and IPV6_RECVxxx. (2) is
controversial. Someone says the uniform behavior is important, while
someone says using most application programmers are not familiar with
using recvmsg() on TCP sockets...etc.
Meanwhile, there is actually no usage of receiving the optional
information on TCP sockets. And, actually, we cannot expect to use
the information just like on UDP/raw sockets (e.g. for access
control), and some information such as the destination address is
meaningless for TCP sockets.
The lack of usage also means that backward compatibility to existing
implementations does not matter (much), so we can basically take either
approach. However, we could not reach consensus on a particular
behavior, and the comparison between (a) and (b) was quite
controversial (someone said (a) is simpler, while some other guy said
(b) is simpler, etc.)
With the fact of the lack of usage and consensus on a particular
behavior, I believe the best current approach is to just leave this
mechanism unspecified.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
