Paul Hoffman wrote:
Why not? As long as the reader of the IANA registry can ascertain
which codepoint owner is at a particular level, how would that affect
interop?
Being able to ascertain what the level is isn't enough; you also
need to know (and more importantly, care) about the
At 12:10 PM +0300 6/15/07, [EMAIL PROTECTED] wrote:
Paul Hoffman wrote:
Why not? As long as the reader of the IANA registry can ascertain
which codepoint owner is at a particular level, how would that affect
interop?
Being able to ascertain what the level is isn't enough; you also
need to
At 7:27 AM +0300 6/14/07, [EMAIL PROTECTED] wrote:
I think giving out codepoints freely would in many cases encourage
having multiple (often half-baked) solutions to the same problem.
This is the crux of the issue. Does the IETF want to control bad
ideas through the IETF process *and* the
, June 14, 2007 10:46 AM
To: [EMAIL PROTECTED]; ietf@ietf.org
Subject: RE: IANA registration constraints (was: Re:
Withdrawing sponsorship...)
At 7:27 AM +0300 6/14/07, [EMAIL PROTECTED] wrote:
I think giving out codepoints freely would in many cases encourage
having multiple (often half-baked
John C Klensin wrote:
To me, the fundamental question here is whether, in the last
analysis, we consider it more important to have
* the best and most extensive Internet interoperability
possible or
* a maximum of real or imagined IETF control over all
At 12:08 PM +0300 6/13/07, [EMAIL PROTECTED] wrote:
The hurdle of getting IETF consensus and publishing an RFC does
weed out many crazy proposals that, in all fairness, would not
have made the Internet work better, and would not have promoted
interoperability.
It does not need to promote
--On Wednesday, June 13, 2007 08:27 -0700 Paul Hoffman
[EMAIL PROTECTED] wrote:
At 12:08 PM +0300 6/13/07, [EMAIL PROTECTED] wrote:
The hurdle of getting IETF consensus and publishing an RFC
does weed out many crazy proposals that, in all fairness,
would not have made the Internet work
John Klensin,
You wrote:
*
* I think real specifications of what the requested parameter will
* mean and be used for are important. I think there is a
* difference between registering a parameter for a non-standard
* specification that is already deployed and in successful use
Bob Braden writes:
I would note that the purveyors of a non-standard specification that
is already deployed and in successful use must have somehow obtained
their own number assignment without the IANA's help, or this
situation could not arise. And before that specification was
successfully
a policy layer.
-Original Message-
From: Bob Braden [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 13, 2007 2:58 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: ietf@ietf.org
Subject: Re: IANA registration constraints (was: Re:
Withdrawing sponsorship
On Wed, 13 Jun 2007, Arnt Gulbrandsen wrote:
Cases like managesieve. Managesieve is almost a decade old and in real
use at many sites. Tens of thousands? Even more? No idea. The port it
uses was allocated to another purpose about four years after managesieve
was deployed.
The smtps port was
--On Wednesday, June 13, 2007 11:58 -0700 Bob Braden
[EMAIL PROTECTED] wrote:
John Klensin,
You wrote:
*
* I think real specifications of what the requested
parameter will* mean and be used for are important. I
think there is a* difference between registering a
parameter
Tony Finch wrote:
On Wed, 13 Jun 2007, Arnt Gulbrandsen wrote:
Cases like managesieve. Managesieve is almost a decade old and in real
use at many sites. Tens of thousands? Even more? No idea. The port it
uses was allocated to another purpose about four years after managesieve
was deployed.
Paul Hoffman wrote:
At 12:08 PM +0300 6/13/07, [EMAIL PROTECTED] wrote:
The hurdle of getting IETF consensus and publishing an RFC does
weed out many crazy proposals that, in all fairness, would not
have made the Internet work better, and would not have promoted
interoperability.
It does
John C Klensin wrote:
There may be things that make this particular case special, but, for the
general case, I have gradually come to think that model is broken. The
problem is that the IETF cannot _prevent_ someone from making up a
parameter and using it, registered or not, nor can we
15 matches
Mail list logo
