>
> > As I said in the today's meeting, please speak up about your opinions,
> > if you're interested in implementing the API. I'd like to collect the
> > opinions, and will soon revise the draft based on consensus.
>
> I think the current (-03, and RFC 2292) definition is fine. For 2292
> implementors, there is no new benefit introduced by recvmsg() in
> previous revision of the draft. Even use of recvmsg(), an application
> cannot follow the changes of extension headers of duplicated segment,
> ACK, RST, FIN.
>
> Actually, I believe most of TCP applications will use neither of
> recvmsg() or getsockopt() to get extention headers or some other
> infomration, because the connection establishment using SYN/ACK is
> automatically made regardless application's behavior.
>
This is almost certainly true.
> So I prefer simplest definition to implement such feature if it is
> included in the specification. That's why I think current specification
> (-03 draft) is better.
>
Simplest is in the eye of the beholder. We have implemented the -02
behavior and the -03 behavior in the past. I would not agree that the -03
behavior is simpler is any respect.
Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
