>
> > 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.
>
> So we all have implemented the -03 behavior. Why changes are needed?
> The -03 behavior, which is almost same as existing RFC 2292 behavior,
> works fine even for receive only applications or with shutdown.
>
Yes, we implemented something like the -03 behavior four years ago. There
is little reason to resurrect it since the -02 behavior was specified almost
three years ago, has been implemented and works.
I don't know who "we all" is here. I don't believe Vlad's team has implemented
the -03 behavior and while we have implemented it in the past we don't really
care to bring it back. The -02 behavior has been specified for almost three
years. It has been implemented and shipped. There seems to be no clear
consensus for a change (3 for, 2 against).
> I believe that the reason for recvmsg() raised in 2292bis was to trace
> the changes in extension headers and other parameters for receiving
> applications. But it is obviously impossible for TCP.
>
Impossible seems to be a strong word. I don't agree.
> So the only reason to keep -02 behavior would be similarity for UDP.
> Most of TCP applications is not so similar to UDP and required changes
> for existing TCP applications is minimum in -03, IMO.
>
Since there doesn't seem to be consensus for the change made between -02
and -03 the -02 behavior should hold. If not then both mechanisms should
be excised from the document. We have wasted enough time on a facility of
dubious value.
tim
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
