On 22.04.2010 00:46, Martin Rex wrote:
Julian Reschke wrote:
I was recently pointed at:
http://tools.ietf.org/html/rfc5226#section-4.2:
All such URLs,
however, will be removed from the RFC prior to final
On Apr 22, 2010, at 1:46 AM, Martin Rex wrote:
It might be worse than that, actually.
When RFC-5746 was recently published, the URL from an extremely useful
informative reference apparently got stripped by the RFC Editor:
draft -03:
[Ray09]Ray, M., Authentication Gap in TLS
On 22.04.2010 07:59, Yoav Nir wrote:
When RFC-5746 was recently published, the URL from an extremely useful
informative reference apparently got stripped by the RFC Editor:
draft -03:
[Ray09]Ray, M., Authentication Gap in TLS Renegotiation,
November
On 22.04.2010 06:42, Mark Nottingham wrote:
For the issues around formats, have you considered using content negotiation?
http://www.apps.ietf.org/rfc/rfc2616.html#sec-12.1
+1
WRT XHTML, it's a candidate for deprecation for a different reason; the W3C is
moving away from XHTML as part
I'll defer to Julian on matters of HTML; he's braver than I ;)
On 22/04/2010, at 5:01 PM, Julian Reschke wrote:
On 22.04.2010 06:42, Mark Nottingham wrote:
For the issues around formats, have you considered using content negotiation?
http://www.apps.ietf.org/rfc/rfc2616.html#sec-12.1
On 21.04.2010 23:06, Kim Davies wrote:
Hi all,
A few comments from the perspective of IANA staff maintaining the website
infrastructure:
Appreciated!
...
c) To my mind, a central question is not the preservation of the URI, but what is the
expectation of preserving the format of the
[Replying to Mark, only because he inspired to make the remark]
On Apr 19, 2010, at 5:21 AM, Mark Nottingham wrote:
Couldn't IANA just implement the search format as
http://www.iana.org/assignments/Registry-Name
and cut out the middle man?
Regarding the 20 year argument, it seems to
Document: draft-ietf-avt-register-srtp-02
Reviewer: Enrico Marocco
Review Date: 2010-04-22
IESG Telechat date: 2010-04-22
Summary: This draft is basically ready for publication as a Proposed
Standard. I found a minor nit that would be fixed by the Editor anyway.
Note: The main issue with this
Julian Reschke julian.resc...@gmx.de writes:
On 22.04.2010 07:59, Yoav Nir wrote:
When RFC-5746 was recently published, the URL from an extremely useful
informative reference apparently got stripped by the RFC Editor:
draft -03:
[Ray09]Ray, M., Authentication Gap in TLS
That's a GREAT document and it makes me feel much better; thanks!
A bit of feedback:
* Section 2.1: The registry operator maintains public mailing lists as
specified in IANA Considerations -- is this always true? Many of the lists are
@ietf.org; do they operate these as well?
* Section 3:
On 22.04.2010 11:32, Simon Josefsson wrote:
Julian Reschkejulian.resc...@gmx.de writes:
...
It is easy to fail to catch a change like that, even if you are an
author.
...
I have learned the hard way to repeat all RFC Editor edits in my copy of
the draft, and only to approve publication when
For what it's worth, there was (Once Upon A Time) a working group called
TCPIMPL (TCP Implementation), that published an don't do it like this
RFC (http://www.ietf.org/rfc/rfc2525.txt), that didn't call out vendor X,
but DID provide traces from implementations that violated the spec, and
On 4/22/2010 3:35 AM, Spencer Dawkins wrote:
For what it's worth, there was (Once Upon A Time) a working group called
TCPIMPL (TCP Implementation), that published an don't do it like
this RFC (http://www.ietf.org/rfc/rfc2525.txt), that didn't call out
vendor X, but DID provide traces from
Paul Hoffman wrote:
Without a rationale for when the extension is useful, it is impossible
for implementers to know when use of this extension is warranted or not.
The environment I described in the earlier thread is TLS with
Diffie-Hellman. I thought that saying that was sufficient, but
On Thu, Apr 22, 2010 at 4:29 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:
In which environments is the extension useful?
The only motivation in the document that I can find is this:
In some application environments, it is desirable to have the client
and/or the server be able to input more
Paul Hoffman wrote:
In Diffie-Hellman key establishment with static keys, even if the PRNG
of one side is bad, the resulting pre-master secret is still sound.
TLS needs _more_ than the secrecy of the pre-master secret to be secure.
Snippets from rfc-5246 (TLS v1.2):
(I've changed the subject line because this topic might interest
members of the community who have long since tuned out the
Pointers to IANA... topic.)
Below...
--On Thursday, April 22, 2010 11:50 +0200 Julian Reschke
julian.resc...@gmx.de wrote:
...
In some cases there's also a considerable
The introduction of this I-D is very, very thin, and, more importantly,
there's no applicability information. I have asked before and gotten no
additional information. I've also suggested one use for this that the
author rejected on the grounds, IIRC, that this extension is not
intended for that
On Wed, Apr 21, 2010 at 10:27:03AM -0700, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Master Secret Inputs for TLS '
draft-hoffman-tls-master-secret-input-01.txt as a Proposed Standard
I support
I might drift slightly toward there should be a published Internet-Draft
that differs only in formatting-as-an-RFC from what is published as an RFC,
but would be willing to listen to arguments that this is too strict - but I
broadly agree with what's said below.
Spencer
(I've changed the
Nicolas Williams wrote:
On Wed, Apr 21, 2010 at 10:27:03AM -0700, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Master Secret Inputs for TLS '
draft-hoffman-tls-master-secret-input-01.txt as a
--On Thursday, April 22, 2010 13:27 -0500 Spencer Dawkins
spen...@wonderhamster.org wrote:
I might drift slightly toward there should be a published
Internet-Draft that differs only in formatting-as-an-RFC from
what is published as an RFC, but would be willing to listen
to arguments that
If I may comment from my position as ex-RSE, the RFC Editor's policy for
at least the past 10 years has been to fuss at authors who ask for
substantive changes in AUTH48, but then to follow the dictum: better to
get it right than get it early. In other words, the RFC Editor did push
back but
Bob,
I hope we all agree with that. There can be a difficulty, however,
if the apparently obvious and correct technical fix actually has
implications beyond the obvious that might be picked up by renewed
WG discussion or even a repeat Last Call.
But I think we would be foolish to legislate on
Brian E Carpenter wrote:
There can be a difficulty, however,
if the apparently obvious and correct technical fix actually has
implications beyond the obvious that might be picked up by renewed
WG discussion or even a repeat Last Call.
But I think we would be
--On Thursday, April 22, 2010 13:23 -0700 Bob Braden
bra...@isi.edu wrote:
If I may comment from my position as ex-RSE, the RFC Editor's
policy for at least the past 10 years has been to fuss at
authors who ask for substantive changes in AUTH48, but then to
follow the dictum: better to get
--On Thursday, April 22, 2010 23:45 +0200 Martin Rex
m...@sap.com wrote:
Maybe this is much more of a tools than of a procedural issue?
(I personally don't know the AUTH48 and editing process).
If the RFC Editor would provide his edited document back to the
document author in a format
Total of 97 messages in the last 7 days.
script run at: Fri Apr 23 00:53:02 EDT 2010
Messages | Bytes| Who
+--++--+
8.25% |8 | 6.72% |40269 | julian.resc...@gmx.de
7.22% |7 | 5.77% |34589 |
The IESG has approved the following document:
- 'A Recommendation for IPv6 Address Text Representation '
draft-ietf-6man-text-addr-representation-07.txt as a Proposed Standard
This document is the product of the IPv6 Maintenance Working Group.
The IESG contact persons are Jari Arkko and
29 matches
Mail list logo
