Eric Rescorla wrote:
I agree that these specs should explicitly specify which TLS version
to support. As a practical matter, this is either 1.0 or 1.1, since
1.2 is not yet finished. Unfortunately, which one to require isn't
really something that can be decided on technical grounds: the
On 2007-05-22 07:51, Philip Guenther wrote:
On Mon, 21 May 2007, Jeffrey Hutzelman wrote:
...
It seems to me that specs should _not_ explicitly specify which TLS
version to support, and should instead refer to an STD number.
Applications don't generally specify which verisons of IP or TCP to
On Tue, 22 May 2007, Brian E Carpenter wrote:
On 2007-05-22 07:51, Philip Guenther wrote:
...
We expect application protocols that require TLS to specify a mandatory-
-to-implement ciphersuite to guarantee interoperability between clients and
servers. How is the TLS version any different? A
Philip Guenther guenther plus ietfd at sendmail dot com wrote:
That's a clearer version of what I meant, yes. I certainly didn't mean
must _only_ support specific version X.Y.
It would probably be wise to have some canned words for this be provided
by true TLS experts to avoid subtle
On 5/19/07, Tim Bray [EMAIL PROTECTED] wrote:
Well Rob, I think the community at large and the IESG in particular
would welcome suggestions on what to do with this one.
Sorry Tim, can't agree with that assertion. At least some people seem
to be content with handwaving, if the current Atompub
On Sunday, May 20, 2007 01:41:29 PM -0700 Eric Rescorla
[EMAIL PROTECTED] wrote:
I agree that these specs should explicitly specify which TLS version
to support. As a practical matter, this is either 1.0 or 1.1, since
1.2 is not yet finished. Unfortunately, which one to require isn't
really
On Mon, 21 May 2007, Jeffrey Hutzelman wrote:
...
It seems to me that specs should _not_ explicitly specify which TLS version
to support, and should instead refer to an STD number. Applications don't
generally specify which verisons of IP or TCP to use, and TLS is at a similar
level of
Tim Bray wrote:
On 5/18/07, Robert Sayre [EMAIL PROTECTED] wrote:
I think the substituted text is inadequate, because it is not clear
which TLS version implementors MUST support. As I understand it, the
fact that it is tricky, implying there may be trade-offs, is not
sufficient to avoid
At Sun, 20 May 2007 15:04:54 +0200,
Julian Reschke wrote:
Tim Bray wrote:
On 5/18/07, Robert Sayre [EMAIL PROTECTED] wrote:
I think the substituted text is inadequate, because it is not clear
which TLS version implementors MUST support. As I understand it, the
fact that it is tricky,
At Sat, 19 May 2007 20:34:06 -0700,
Tim Bray wrote:
On 5/18/07, Robert Sayre [EMAIL PROTECTED] wrote:
I think the substituted text is inadequate, because it is not clear
which TLS version implementors MUST support. As I understand it, the
fact that it is tricky, implying there may be
Robert Sayre wrote:
Here's a diff of the changes since last call:
http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-15-from-14.diff.html
It's not clear whether there will be another last call, though I think
there should be. So, I will leave my comments again. I didn't see any
On 3/14/07, EKR [EMAIL PROTECTED] wrote:
Julian Reschke [EMAIL PROTECTED] writes:
As pointed out before, that text really is confusing. As a reader. I'm
left wondering whether I need to implement RFC2246 or RFC4346. Or both?
I wish I knew the answer to this question as well... :)
Hi Robert,
--On March 13, 2007 3:23:22 PM -0400 Robert Sayre [EMAIL PROTECTED]
wrote:
This text is actively misleading, because it suggests RFC 4346 is
included for informational purposes. The text should read:
At a minimum, client and server implementations MUST be capable of
being
On 2007-03-13 20:43, Cyrus Daboo wrote:
Hi Robert,
--On March 13, 2007 3:23:22 PM -0400 Robert Sayre [EMAIL PROTECTED]
wrote:
This text is actively misleading, because it suggests RFC 4346 is
included for informational purposes. The text should read:
At a minimum, client and server
Brian E Carpenter schrieb:
On 2007-03-13 20:43, Cyrus Daboo wrote:
The text that got used in CalDAV (which is about to be published) is:
o MUST support transport over TLS [RFC2246] as defined in [RFC2818]
(note that [RFC2246] has been obsoleted by [RFC4346]);
with 2246, 2818 and 4346
Julian Reschke [EMAIL PROTECTED] writes:
Brian E Carpenter schrieb:
On 2007-03-13 20:43, Cyrus Daboo wrote:
The text that got used in CalDAV (which is about to be published) is:
o MUST support transport over TLS [RFC2246] as defined in [RFC2818]
(note that [RFC2246] has been
From the draft:
At a minimum, client and server implementations MUST be capable of
being configured to use HTTP Basic Authentication [RFC2617] in
conjunction with a TLS connection as specified by [RFC2818]. See
[RFC4346] for more information on TLS.
I've discovered a small but potentially
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert From the draft:
At a minimum, client and server implementations MUST be capable
of being configured to use HTTP Basic Authentication [RFC2617]
in conjunction with a TLS connection as specified by [RFC2818].
See
Sam Hartman wrote:
My preference is to resolve this by making 2818 normative; I believe
we've already 3967'd 2818 so we don't need an additional last call on
this one.
Is RFC 2818 sufficient to ensure interoperability? It would be quite
easy for two implementations to claim to implement
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert Sam Hartman wrote:
My preference is to resolve this by making 2818 normative; I
believe we've already 3967'd 2818 so we don't need an
additional last call on this one.
Robert Is RFC 2818 sufficient to ensure
Sam Hartman wrote:
I think both 2818 and 4346 contain important details and need to be
normative.
That makes sense to me. However, I initially thought the references had
been mistakenly switched around.
From the draft:
At a minimum, client and server implementations MUST be capable of
21 matches
Mail list logo
