Ned Freed quotes Jari Arkko:
(That being said, I wonder if some tool magic would display these
references as pointers, just as already happens for normal references.)
1925, 6a.
This wierd resistance to including useful information in our documents
may have made some small amount of sense in
The IETF has in fact already got a URN defined for its documents, it
is just not a locatable identifier at the current time.
I used the URN form of the documents in XKMS to specify the protocol
that a key is being requested for use with. That is one case where you
want to have a fixed identifier
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just
On Tue, Apr 20, 2010 at 8:07 PM, ned+i...@mauve.mrochek.com wrote:
This wierd resistance to including useful information in our documents may
have
made some small amount of sense in the past when things were less clear. It
is
completely silly and totally counterproductive now.
The weird
The IETF Last Call draft-lawrence-sipforum-user-agent-config ended
yesterday (it began 2010-03-23).
Abstract:
This document defines procedures for how a SIP User Agent should
locate, retrieve, and maintain current configuration information from
a Configuration Service.
This document
Hi all,
A few comments from the perspective of IANA staff maintaining the website
infrastructure:
a) This is a timely discussion as we have been discussing this very issue
internally. The thought was coming up with better guidance on referencing IANA
registries in such a way the provides
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Random Extension to TLS '
draft-hoffman-tls-additional-random-ext-01.txt as a Proposed Standard
I'm somewhat confused to see a Last Call for this proposal.
At 12:05 AM +0200 4/22/10, Martin Rex wrote:
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Random Extension to TLS '
draft-hoffman-tls-additional-random-ext-01.txt as a Proposed Standard
I'm somewhat
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
publication.
I have to say that I think
Paul Hoffman paul.hoff...@vpnc.org writes:
At 12:05 AM +0200 4/22/10, Martin Rex wrote:
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Random Extension to TLS '
draft-hoffman-tls-additional-random-ext-01.txt
Paul Hoffman wrote:
At 12:05 AM +0200 4/22/10, Martin Rex wrote:
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Random Extension to TLS '
draft-hoffman-tls-additional-random-ext-01.txt as a Proposed
I see that this (still the same version) is On agenda of 2010-05-06
IESG telechat, and I must say I'm a little surprised, since I counted
seven clear objections to the document and no strong supporting
comments. Also, IANA said IANA does not understand the implications
of the IANA Actions
everyone--
After just now finding the root cause of yet another stupid interoperability
problem to be an interaction between a client not choosing a sufficiently
unique host/session identifier and a server being overly clever about using
said identifiers for purposes other than intended in the
On 04/21/2010 05:55 PM, james woodyatt wrote:
everyone--
After just now finding the root cause of yet another stupid
interoperability problem to be an interaction between a client not
choosing a sufficiently unique host/session identifier and a server
being overly clever about using said
For the issues around formats, have you considered using content negotiation?
http://www.apps.ietf.org/rfc/rfc2616.html#sec-12.1
WRT XHTML, it's a candidate for deprecation for a different reason; the W3C is
moving away from XHTML as part of the HTML5 effort. Current fashion for this
type of
On 22 Apr 2010, at 01:55, james woodyatt wrote:
After just now finding the root cause of yet another stupid interoperability
problem to be an interaction between a client not choosing a sufficiently
unique host/session identifier and a server being overly clever about using
said identifiers
How about a Real World Deployment wiki page linked from each RFC, where
implementers can insert comments like Don't do like vendor xxx - don't always
set the nonce to zero.
Hopefully vendor xxx fixes it in the next release, and changes the page to read
Don't do like vendor xxx did prior to
The IESG has received a request from an individual submitter to consider
the following document:
- 'An EAP Authentication Method Based on the EKE Protocol '
draft-sheffer-emu-eap-eke-06.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has received a request from an individual submitter to consider
the following document:
- 'Additional Random Extension to TLS '
draft-hoffman-tls-additional-random-ext-01.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments
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
The IESG plans to make a decision in the next few weeks, and solicits
final
20 matches
Mail list logo
