>>>>> On Tue, 18 Dec 2001 10:53:17 -0500,
>>>>> Vladislav Yasevich <[EMAIL PROTECTED]> said:
>> With this reality, the received optional information can only be
>> used as "informational" in the sense of the word. This also means
>> that it is meaningless to try to receive the optional information
>> for as many received segments as possible.
>>
>> So, using recvmsg() with ancillary data has less advantage over the
>> RFC 2292 behavior, at least IMHO.
> I don't understand why you are assigning advantage to the 2292 behavior.
> So far, both methods provide identical functionality as far
> as the headers received by the application.
> IMO, both versions add additional complexity to the application, but only
> at the request of the application.
Correct, but I did not intend to assign advantage to 2292. I just
said that 2292bis-02 did not have advantage to 2292 (or 2292bis-03).
>> Meanwhile, using recvmsg() causes additional issues, such as impact
>> on the socket semantics or the "send-only apps" problem, which did
>> not exist in the RFC 2292 behavior.
> Are you conserned about not being able to access the extension headers
> sent with ACKs, RSTs, etc...?
> Is this really something that would be usefull to an application?
Well, I'm not sure. But, actually, I'm not even sure if passing the
received extension headers to applications is really useful at all.
So, we're discussing a corner case of not-so-useful feature, and
that's why I'm inclined to leave this topic unspecified.
>> As for the ability to receive optional information at a send-only
>> application, it might be true that there is less meaningful usage of
>> the ability. But, anyway, RFC 2292 (and 2292bis-03) provides the
>> ability, while rfc2292bis-02 (and earlier) does not.
> I think providing a meaningless ability is pointless and makes for feature
> bloat and complexity. It is not a good argument to do something.
>> In summary, the rfc2292bis-02 behavior has disadvantage over the
>> RFC2292 behavior without an (less) advantage.
>>
>> That's why I, for one, prefer the 03 behavior. But I admit that the
>> advantage (03 over 02) is not so big and one may say that the
>> advantage is not worth the change. (perhaps I should have just put
>> the issue in the "open issues" section. that was my bad.)
> I prefer the 02 behavior because it is cleaner conseptually. Yes it requires
> code changes for the apps wanting to use it, but most applications do not
> need and will not use this feature.
(same argument as above applies here.)
>> Again, though I prefer the 03 behavior, I know (and understand) some
>> other people dislike it. I'll hear from others, and will obey the
>> consensus.
> If we can not reach consensus (don't gasp, it happened before), may I suggest
> that we document both behaviors. We can keep a strict 2292bis-02 behavior
> (i.e
> don't return control data for SYNs, ACKs, etc), and the 2292bis-03 behavior
> with
> the limitations in section 4.1 (i.e applies only to TCP and can only be used
> with
> getsockopt).
This would also be a possible approach, but I agree with Tim here. If
we describe some behavior anyway, we should take one and only one
mechanism. Otherwise it just causes additional complexity and less
portability.
But, again, I'd rather leave this spec unspecified, because we're
talking about something that we're not even sure about the usefulness.
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]
--------------------------------------------------------------------
