> 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. 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. Atsushi Onoe -------------------------------------------------------------------- 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] --------------------------------------------------------------------
