On Sun Feb 19 23:23:59 2006, Dave Crocker wrote:
Folks,
Eric said:
1. It is slower because it requires two handshakes.
2. The client may have to authenticate twice (this is a special
case of (1)).
The second case can be easily ameliorated by having the client
send an
extension (empty
Sharing personal experience:
As a Norway-based user, I do worry about anything that adds extra round
trips to my queries to US-based websites. The user experience seen from
California is really quite different from the user experience here in
Norway - about 200 ms * number of round trips
Mr. Morfin:
Your interest is noted.
-Scott-
-Original Message-
From: Jefsey Morfin [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 19, 2006 10:46 PM
To: Scott Hollenbeck; iesg@ietf.org
Cc: ietf@ietf.org
Subject: Nomination for the appointment of a Languages
Subtags Reviewer
Bill Strahm wrote:
I saw all of the huff, and while I agree with it, I am more
concerned about
Appendix A. IPR Disclosure
TBD
What does that mean, and more specifically is a document with a
TBD section really ready for last call at all ?
RFC 3979 Section 11 title says it all:
Hi,
RFC 959, says that FTP supports two modes to transfer files -- ASCII
and Binary. Now, if I have a UTF-8 (or any other encoding) encoded text
file, containing, say Japanese characters, would it be correct to
choose the transfer mode as ASCII? And if I choose the transfer mode as
ASCII, is
Dave Cridland [EMAIL PROTECTED] writes:
On Sun Feb 19 23:23:59 2006, Dave Crocker wrote:
Folks,
Eric said:
1. It is slower because it requires two handshakes.
2. The client may have to authenticate twice (this is a special
case of (1)).
The second case can be easily ameliorated by
- Original Message -
From: Yaakov Stein [EMAIL PROTECTED]
To: Tom.Petch [EMAIL PROTECTED]; Elwyn Davies
[EMAIL PROTECTED]
Cc: ietf ietf@ietf.org
Sent: Sunday, February 19, 2006 7:10 AM
Subject: RE: 'monotonic increasing'
Actually, even mathematicians don't agree on the wording here.
In
Well, I'm not claiming that latency isn't a factor in protocol
performance. What I'm claiming is that it's not clear that latency
in the initial connection setup handshake (in this case the TLS
one) is a major factor in protocol performance. Recall that the
way that TLS works is that you do an
From: Eliot Lear [mailto:[EMAIL PROTECTED]
Hallam-Baker, Phillip wrote:
That overlooks the fact that often the protocol is written up after
the experiment, the results of which are described elsewhere.
The main ongoing experiments are of the form: 'I believe that the
protocol
But just to be clear, if you saw a reference to 'monotonic increasing'
in an American journal,
say of applied mathematics, would you be sure you understood what was
meant?
That would depend on the subject matter.
If the article was on real analysis (where the domain is
nondenumerable),
Once upon a time the used to be computers speaking ASCII or EBCDIC. The
ASCII computers where unix mostly. The EBCDIC where mainframes. ASCII
mode meant that EBCDIC card decks with fixed lenght of mostly 80 characters
per line would be translated into variable lenght records terminated by
CR/LF
Well, for those of us looking at Lemonade, etc, I think we're still
very concerned about every round-trip.
Well, I'm not claiming that latency isn't a factor in protocol
performance. What I'm claiming is that it's not clear that latency
in the initial connection setup handshake (in this
Keith Moore moore@cs.utk.edu writes:
Well, I'm not claiming that latency isn't a factor in protocol
performance. What I'm claiming is that it's not clear that latency
in the initial connection setup handshake (in this case the TLS
one) is a major factor in protocol performance. Recall that
Phil,
Experimental seems inappropriate if really what is going on is that
there is no consensus as to how to do something. If the RFC documents
existing practice and won't break anything (and in particular won't
break anything needlessly), then I would say another attempt via
independent
On Mon, 20 Feb 2006, Dave Cridland wrote:
For IMAP, where connection setup time is, in principle, a very small part of
the total session time, it seems odd you're advocating that nobody should
worry about adding round-trips when there's been substantial effort in
reducing round-trips in
The best solution to this problem is to avoid the use of technical
vocabulary and use plain English and unambiguous formulas.
It is quite easy to see how the term 'strictly monotonic' gets
abreviated to 'monotonic' when used by non-mathematicians.
I am pretty sure that if we started using the
In message [EMAIL PROTECTED], Dave Crocker writes:
I'll add one specific comment, reacting to Steve Bellovin's noting LAN vs. WAN
operational environment distinction. It has been my experience and my
understanding that the IETF does not design upper-level (transport and above)
protocols to be
--On Monday, 20 February, 2006 17:25 +0100 Peter Dambier
[EMAIL PROTECTED] wrote:
Once upon a time the used to be computers speaking ASCII or
EBCDIC. The ASCII computers where unix mostly.
...
Actually, Peter, at the time FTP was designed, the ASCII
computers were mostly PDP-10s running
Sam,
I re-inserted JFC's original text below.
Just to be clear, it looks as if JFC has some misunderstanding
of IETF mailing lists, or - perhaps - knows of IETF mailing lists I
am not aware of. Also, most of the formality he points out is both
reasonable, and not in disagreement
Steve,
Dave, I tried to phrase my comment carefully. I wrote:
1. You succeeded.
2. For my own part, I had no doubt that your model of the world had something
like the rules you listed.
3. My reason for citing your note was that the issue of expected usage
environment is, I think,
Russ, et al,
There is a precedent that may need to be established here that
is not relevant to the TLS Working Group (therefore their omission in
the CC list above).
The text to that Bill refers to actually says the following:
These notices may not be used with any
JFC,
This appears to be an appeal in response to an action
that - as far as I can tell - has not yet occurred. Scott's
posting of the intent to consider does not appear to be any
thing to which an appeal is appropriate, the dead-line for
submission of comments was last Friday and - again
Tom/Yaakov,
Getting back to the slightly related field of specification
of standard protocols, the term monotonically increasing is used
in many cases because that is all that really needs to be said.
This is because the intent in the specification is to allow
implementations to
Dear Eric,
I certainly agree with all your synthesis.
I just want to clarify about the lists I would know.
There are lists which may have a receive considerable discretionnary
powers such as IANA registry reviewers. They need authority. Such
lists are the lists I considered. After all ICANN is
John C Klensin wrote:
Sandeep's question raises another interesting issue. I just
went back and reread RFC 2640. It does not seem to address the
TYPE A issue at all. It does say (Section 2, paragraph 1)
Clients and servers are, however, under no obligation to
perform any conversion on
First of all thanks to everybody for the response.
I knew that a FTP transfer in ASCII mode does EOL and EOF conversions
based on the OS of the receiving system. And I very much expected my
UTF-8 encoded file to get garbled when I FTPied it in ASCII mode. But
guess what, it was not garbled on the
The IESG has approved the following document:
- 'Repeated Authentication in IKEv2 '
draft-nir-ikev2-auth-lt-05.txt as an Experimental RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Russ Housley.
A URL of this
The IESG has approved the following document:
- 'Sieve Extension: Relational Tests '
draft-ietf-sieve-3431bis-04.txt as a Proposed Standard
This document is the product of the Sieve Mail Filtering Language Working
Group.
The IESG contact persons are Scott Hollenbeck and Ted Hardie.
A URL
The IESG has approved the following document:
- 'Using the GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 algorithms
with the Internet X.509 Public Key Infrastructure Certificate and CRL
Profile. '
draft-ietf-pkix-gost-cppk-05.txt as a Proposed Standard
This document is the
The IESG has approved the following document:
- 'Mobile IPv6 and Firewalls: Problem statement '
draft-ietf-mip6-firewalls-04.txt as an Informational RFC
This document is the product of the Mobility for IPv6 Working Group.
The IESG contact persons are Margaret Wasserman and Mark Townsley.
A
The IESG has approved the following document:
- 'DHCP: IPv4 and IPv6 Dual-Stack Issues '
draft-ietf-dhc-dual-stack-04.txt as an Informational RFC
This document is the product of the Dynamic Host Configuration Working Group.
The IESG contact persons are Margaret Wasserman and Mark Townsley.
31 matches
Mail list logo
