>> So what you're saying is that we should let somebody make up some 
>> mangled mess of a system, and then stamp it as a "standard", rather 
>> than designing something properly?
> 
> No. I'm saying that if you're going to standardize something, you should 
> either standardize what people are already doing, or standardize what 
> people aren't yet doing, rather than trying to "standardize" what people 
> are already doing but in a different way.

Wait - so you're saying you should write the standard before people 
start trying to implement stuff?

That at least makes sense.

>> Stuff like making something like Flash a standard rather than 
>> designing SVG? And the single proprietry implementation should be the 
>> standard spec?
>>
>> Isn't that exactly why everybody's so upset with the MS document 
>> "standard"?
> 
> You obviously missed the part where I mentions "multiple inteoperating 
> implementations available to the public", right?

It just seems to me that the chances of (say) two companies both 
deciding to invent something like USB at the same time, and it being 
interoperable, are so vanishingly small as to not be worth even 
considering. You need a standard to work to or nothing will ever 
interoperate.

Post a reply to this message

Invisible wrote:
> Wait - so you're saying you should write the standard before people 
> start trying to implement stuff?

Or after it's already finished. One or the other. Don't try to standardize 
what's already widely deployed unless what you're standardizing is the parts 
that are common to everyone.

>> You obviously missed the part where I mentions "multiple inteoperating 
>> implementations available to the public", right?
> 
> It just seems to me that the chances of (say) two companies both 
> deciding to invent something like USB at the same time, and it being 
> interoperable, are so vanishingly small as to not be worth even 
> considering. You need a standard to work to or nothing will ever 
> interoperate.

No. They can work together to make the standard, and then not accept the 
standard as a standard until it's already working. That's the IETF and ISO 
standards process.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

>> It just seems to me that the chances of (say) two companies both 
>> deciding to invent something like USB at the same time, and it being 
>> interoperable, are so vanishingly small as to not be worth even 
>> considering. You need a standard to work to or nothing will ever 
>> interoperate.
> 
> No. They can work together to make the standard, and then not accept the 
> standard as a standard until it's already working. That's the IETF and 
> ISO standards process.

So... why is the finished standard specificstion called a "request for 
comments"? This has always bothered me...

Post a reply to this message

Invisible wrote:
> So... why is the finished standard specificstion called a "request for 
> comments"? This has always bothered me...

History. :-)  There are a number of phases it goes through, including 
proposal, draft standard, recommended standard, and (I think) required 
standard. There are also requests for comments that aren't intended to ever 
turn into standards.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

>> So... why is the finished standard specificstion called a "request for 
>> comments"? This has always bothered me...
> 
> History. :-)  There are a number of phases it goes through, including 
> proposal, draft standard, recommended standard, and (I think) required 
> standard. There are also requests for comments that aren't intended to 
> ever turn into standards.

And yet, if you look up the defintion of (say) the Routing Information 
Protocol, it's defined in RFC 2453. Which makes it sound like they're 
*requesting* people to comment on a possible standard, rather than 
*defining* a finished standard.

History, I guess. Much like the way that a parcel traveling by car is a 
shipment, and a parcel travelling by ship is cargo... ;-)

Post a reply to this message

Invisible wrote:
> And yet, if you look up the defintion of (say) the Routing Information 
> Protocol, it's defined in RFC 2453.  Which makes it sound like they're
> *requesting* people to comment on a possible standard, rather than 
> *defining* a finished standard.

They were, when it was an RFC. See the line lower down, where it
says "STD: 56"?  That's the standard. :-)

The things start as an RFC. When they're done adjusting to the comments 
received from the request, they get standardized, they get a number, and 
it's still the same RFC. It's just an RFC where nobody had any comments 
about it that weren't addressed. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

>> And yet, if you look up the defintion of (say) the Routing Information 
>> Protocol, it's defined in RFC 2453.  Which makes it sound like they're
>> *requesting* people to comment on a possible standard, rather than 
>> *defining* a finished standard.
> 
> They were, when it was an RFC. See the line lower down, where it
> says "STD: 56"?  That's the standard. :-)

And yet, they're always referred to by the RFC number. (I guess because 
it came first...)

> The things start as an RFC. When they're done adjusting to the comments 
> received from the request, they get standardized, they get a number, and 
> it's still the same RFC. It's just an RFC where nobody had any comments 
> about it that weren't addressed. :-)

Heh. I wonder if there are any RFCs where people said "hell, this is too 
stupid, let's forget the whole thing"?

Worryingly, RFC 2549 does *not* fall into this category...!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> And yet, they're always referred to by the RFC number.

After they're published, yes. Before they're a standard, they don't have a 
number.

> Heh. I wonder if there are any RFCs where people said "hell, this is too 
> stupid, let's forget the whole thing"?

Yes. They don't get numbers, and they don't really stick around.

There's also RFCs that were "draft standards" that stick around but never 
move to the "standard" status.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message