> 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 unspec
> On Fri, 21 Dec 2001 18:25:07 +0100 (CET),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> > Are there TCP applications which use RFC 2292 style for accessing received
>> > extension headers?
>> > I thought we had concluded that no TCP applications existed that access
>> > the received stu
> > Are there TCP applications which use RFC 2292 style for accessing received
> > extension headers?
> > I thought we had concluded that no TCP applications existed that access
> > the received stuff (even tough telnet can set things like routing headers
> > for transmit).
>
> Okay, compatibili
> On Fri, 21 Dec 2001 01:23:45 +0100 (CET),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> 3. there are currently RFC2292-style applications deployed. It is easy
>> for such applications to migrate to rfc2292bis-03 than to
>> rfc2292bis-02. (The opposite argument may apply for
>> rfc2292
> I searched in the web for old discussions and I think I found the
> answer to the question 1. (You can check the discussion at the
> following URL
> http://www.wcug.wwu.edu/lists/ipng/199803/threads.html
> with the subject "Advanced Sockets API Issue")
Thanks for digging up the history - I cou
> On Wed, 19 Dec 2001 13:31:28 -0500,
> Vladislav Yasevich <[EMAIL PROTECTED]> said:
> I've been thinking about the suggestiong of removing
> the tcp handling from the document and keep comming up
> with the following 2 questions:
> 1. Why was the change made origianlly in the 2292bis?
I've been thinking about the suggestiong of removing
the tcp handling from the document and keep comming up
with the following 2 questions:
1. Why was the change made origianlly in the 2292bis?
and
2. Why change now back to the original 2292 definition?
I don't know the answere to 1 (may be
In your previous mail you wrote:
Okay with me, too. I just tried to make the document clear in the 03
draft, but in fact I don't see practical usage of receiving the
optional information on TCP sockets. If we can reach a consensus of
leaving it unspecified (by removing the text), i
JINMEI
Thanks, this is a lot clearer. I'll try to address the points
that you've made since I am still not convinced that we gain
anything by changing the behavior.
JINMEI Tatuya / ¿ÀÌÀãºÈ wrote:
> Perhaps I was not very clear at the presentation. The reason for the
> change (in 03) is NOT s
> 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 informat
> On Tue, 18 Dec 2001 07:34:49 +0100 (CET),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> Okay with me, too. I just tried to make the document clear in the 03
>> draft, but in fact I don't see practical usage of receiving the
>> optional information on TCP sockets. If we can reach a con
Vlad,
>
> >
> > And, of course, either approach has impact on existing
> > implementations, and the impact depends on the spec that the
> > implementations are using. As I said in the presentation, the 02
> > approach affects RFC2292-based implementations much, and the 03
> > appr
> Okay with me, too. I just tried to make the document clear in the 03
> draft, but in fact I don't see practical usage of receiving the
> optional information on TCP sockets. If we can reach a consensus of
> leaving it unspecified (by removing the text), it's just fine.
At one level I don't h
> On Tue, 18 Dec 2001 10:06:11 +0900 (JST),
> Atsushi Onoe <[EMAIL PROTECTED]> said:
>> If not then both mechanisms should
>> be excised from the document.
> Actually, it is acceptable for me.
Okay with me, too. I just tried to make the document clear in the 03
draft, but in fact I do
> If not then both mechanisms should
> be excised from the document.
Actually, it is acceptable for me.
> We have wasted enough time on a facility of
> dubious value.
Agreed.
Atsushi Onoe
IETF IPng Working Group Mailing List
>
> > 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
> 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
>> the major problem I'm seeing for -02 definition is that there's no
>> relationship defined (impossible) between the normal TCP data stream
>> and ancillary data segments. I personally in favor of -03 definition.
>So? I didn't realize that having such a relationship had become a
Itojun,
>
> >> 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 behavio
>> 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
Vlad,
>
> Since you are soliciting comments from implementors, here are my
> opionions about the change ( I was going to wait until I got to work).
>
> I beleave the the 2292bis-02 definition and TCP implications were
> fine. I was curious about the reasons this was put in the draft.
>
I a
>
> > 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
>
> 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, ther
> On Sat, 15 Dec 2001 02:40:18 -0500,
> Vlad Yasevich <[EMAIL PROTECTED]> said:
> Since you are soliciting comments from implementors, here are my
> opionions about the change ( I was going to wait until I got to work).
Thanks for the prompt response (and sorry for urging you. If anyon
Jinmei
Since you are soliciting comments from implementors, here are my
opionions about the change ( I was going to wait until I got to work).
I beleave the the 2292bis-02 definition and TCP implications were
fine. I was curious about the reasons this was put in the draft.
You said at the meet
> On Thu, 13 Dec 2001 11:19:40 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>> An alternative candidate is to allow the stack to pass ancillary data
>> items even without TCP data (recvmsg() would then return 0 in such a
>> case.) With this approach, however, the application may not
> On Mon, 03 Dec 2001 14:24:23 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> An alternative candidate is to allow the stack to pass ancillary data
> items even without TCP data (recvmsg() would then return 0 in such a
> case.) With this approach, however, the application may not be
27 matches
Mail list logo
