Subject: A modest proposal

From: William Jordan <[email-masked]>
Date: Mon, 21 Jan 2013 23:57:22 -0500

I've recent had to write a program to interface with a SIP lync server and
in doing so have had to code to several rfcs.  After reading and dealing
with implementation of the various rfcs I have read I have come up with
what I consider "A modest proposal" to fix some of the problems I've seen
with implementing a rfc.  I think anyone who writes a rfc should have to
provide a working ANSI/C or GNU/C implementation of the rfc in question.
 Specifically, I have worked with the SIP rfc (rfc 3261) and have come to
the conclusion that whoever wrote the rfc has never coded a day in their
life.  Whoever thought it was a good idea to allow multiple ways of doing
the same exact thing would hopefully be deterred by actually writing code
to do it.  I think a suitable punishment for those people would be to write
each way of writing a from header on a blackboard 100 times... this would
actually be less of the pain they've cause by making each writer of a SIP
stack handle each possible way of doing things.

Anyways, that is my modest proposal, please respond or I will be forced to
reply every day to this mailing list on each and every way the SIP spec
sucks one email at a time.  FYI I'm not sure if GNU/C is the correct
acronym, maybe its POSIX/C.

Regards,
Bill

---

From: Melinda Shore <[email-masked]>
Date: Mon, 21 Jan 2013 22:05:27 -0900

On 1/21/13 7:57 PM, William Jordan wrote:
> Whoever thought it was a good idea to
> allow multiple ways of doing the same exact thing would hopefully be
> deterred by actually writing code to do it.  

I think there's general agreement that options are not a good thing and
a pretty decent understanding of the issues around complexity, but
there's many a slip, etc.  I'm sympathetic to your complaints.  At the
time that SIP came along there was much happiness that there was a less
complex alternative to H.323, but for better or worse complicated
problems sometimes have complicated solutions, and SIP ended up a
hairball. I don't think your proposal is likely to go anywhere but I'm
curious about why you're specifically requesting implementations in C.

Melinda

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Jan 2013 08:20:42 +0100

On Jan 22, 2013, at 08:05, Melinda Shore <[email-masked]> wrote:

> why you're specifically requesting implementations in C

I think his argument is that the spec author should be punished for each piece of fluff in the spec.
A sentiment that I can relate to.

Having to write C code probably does qualify as the appropriate punishment :-)

Grüße, Carsten

PS.: The underlying hypothesis that the authors of RFC 3261 don't code can be easily refuted.
But a spec writer who has to code things at the specific instant a new feature is being put into the spec will be in a different, more desirable mindset than someone who can just drop the English and leave implementation as an exercise to the reader.
And too bad we can't have the IESG implement it while reviewing it.
Both would be really useful to curb the "political" fluff that tends to accumulate in our specs.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 21 Jan 2013 22:24:31 -0900

> Having to write C code probably does qualify as the appropriate

I guess that depends on your background ...

> And too bad we can't have the IESG implement it while

There we go.  That would cut down on the "I'll support your
awful idea if you support my awful idea" horse trading.

Melinda

---

From: David Morris <[email-masked]>
Date: Mon, 21 Jan 2013 23:39:08 -0800 (PST)

> awful idea if you support my awful idea" horse trading.

No, it just means that I have to implement my awful idea and
you have to implement yours and then we agree to cross license
the source.

The thing that is easy to forget when viewing a specification
outside of the context of when it was written is that many/most
IETF specs are written to imporve the interoperability of
existing implementations. Part of improving the interoperability
is to incorporate features and/or extensibility to avoid
future hacking. AND we tend to need to grandfather existing
features which we then have to work-around for ever.

And our most popular specifications are the hardest to improve
because of the weight of existing usage.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 22 Jan 2013 10:34:31 +0200

Hi Melinda,

On Jan 22, 2013, at 9:05 AM, Melinda Shore wrote:

> there's general agreement that options are not a good thing and
> there's many a slip, etc. 
It may seem to be very easy to agree with you on that point. However, the story isn't that simple as it first seems to be. 

For example: For SIP there are many different key distribution protocols being specified (see http://tools.ietf.org/html/rfc5479 and http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-01).
Why are there so many different ways to distribute keys for usage with SRTP? Why cannot we just have one solution and always use it? It turns out that there are many reasons, including different properties of individual solutions, designed by other organizations (e.g., 3GPP) and nobody wanted to upset them, IPRs, different architectural assumptions (e.g., regarding regulatory requirements), etc. Even the question whether SRTP should be mandated is already complicated as discussed in http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/

Another example from a different area: Why do we need so many transition technologies for the migration from IPv4 to IPv6? Wouldn't it be less complex to just have one transition mechanism?

Yet another example: Diameter supports TCP and SCTP. RADIUS initially supported UDP only and later added support for TCP. Couldn't the RADIUS guys just have used Diameter if they want to use a reliable transport? 

Ciao
Hannes

---

From: Melinda Shore <[email-masked]>
Date: Tue, 22 Jan 2013 00:49:16 -0900

On 1/21/13 11:34 PM, Hannes Tschofenig wrote:
> It may seem to be very easy to agree with you on that point. However,
> the story isn't that simple as it first seems to be.

Complex problems often have complex solutions.  I think a lot of
people look at sendmail, for example, and go "GAH!" without
knowing much of the history of gatewaying between networks and
the rewrite rules that facilitated that.  But I also wonder how
hard we've worked at trying to reduce complexity in some cases.

The SIP thing is a little painful because at the time it was
brought to the IETF it was touted as a much simpler technology
than H.323.  And, of course, it turned out that ... complex problems
often have complex solutions and there's a reason why H.323 is
as complicated as it is (mostly).  Still, I wonder if we're just
tending to accept complex solutions a bit readily.

Melinda

---

From: t.p. <[email-masked]>
Date: Tue, 22 Jan 2013 09:57:27 +0000

----- Original Message -----
From: "William Jordan" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, January 22, 2013 4:57 AM
> stack handle each possible way of doing things.

I find your proposal puzzling as many of those involved in the creation
of an RFC are experienced coders and do turn out implementations in
short order.  They know, they do not have to write the code, what is
easy to code and what is not.  If a choice is made, to have many
alternatives, which increases the complexity of implementation, then
that choice is made knowingly, in order to produce a protocol that will
better meet the requirements.

Code you write once, a successful implementation will execute a
countless number of times; what matters is that the protocol works every
time, not the length of the one off exercise to implement it beforehand.

If you had said that you had found flaws in the logic of the protocol
which could have been found by coding - and that does happen - then I
think that your argument would carry more weight.

Tom Petch

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 22 Jan 2013 08:03:04 -0800

> acronym, maybe its POSIX/C.

SIP is an RFC so there is nothing that can be done here.  If you want to help,
choose one or more Internet-Drafts, *fully* implement them and report the
problems you find to the Working Group.  I also went through the full 5 steps
of grief over the death of my hope of having a good time implementing IETF
protocols and that's the best way I found of ensuring that RFCs do not suck at
implementation time.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 22 Jan 2013 11:29:04 -0500

Do none of you know what the phrase "a modest proposal" refers to?

Try googling it.

Janet

[email-masked] wrote on 01/21/2013 11:57:22 PM:

> From: William Jordan <[email-masked]>
> To: [email-masked]
> Date: 01/22/2013 12:01 AM
> Subject: A modest proposal
> Sent by: [email-masked]
> 
> I've recent had to write a program to interface with a SIP lync 
> server and in doing so have had to code to several rfcs.  After 
> reading and dealing with implementation of the various rfcs I have 
> read I have come up with what I consider "A modest proposal" to fix 
> some of the problems I've seen with implementing a rfc.  I think 
> anyone who writes a rfc should have to provide a working ANSI/C or 
> GNU/C implementation of the rfc in question.  Specifically, I have 
> worked with the SIP rfc (rfc 3261) and have come to the conclusion 
> that whoever wrote the rfc has never coded a day in their life. 
>  Whoever thought it was a good idea to allow multiple ways of doing 
> the same exact thing would hopefully be deterred by actually writing
> code to do it.  I think a suitable punishment for those people would
> be to write each way of writing a from header on a blackboard 100 
> times... this would actually be less of the pain they've cause by 
> making each writer of a SIP stack handle each possible way of doing 
things.
> 
> Anyways, that is my modest proposal, please respond or I will be 
> forced to reply every day to this mailing list on each and every way
> the SIP spec sucks one email at a time.  FYI I'm not sure if GNU/C 
> is the correct acronym, maybe its POSIX/C.
> 
> Regards,
> Bill

---

From: joel jaeggli <[email-masked]>
Date: Tue, 22 Jan 2013 10:01:22 -0800

> Do none of you know what the phrase "a modest proposal" refers to?
We should kill and eat more internet drafts before they  reach one year 
of age.

---

From: t.p. <[email-masked]>
Date: Tue, 22 Jan 2013 18:02:56 +0000

----- Original Message -----
From: "Janet P Gunn" <[email-masked]>
To: "William Jordan" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 22, 2013 4:29 PM
Subject: Re: A modest proposal

> Do none of you know what the phrase "a modest proposal" refers to?

Or else look through the archives; Margaret explained it very clearly on
August 1st, 2011.

Tom Petch

---

From: "John Levine" <[email-masked]>
Date: 22 Jan 2013 19:20:47 -0000

>Do none of you know what the phrase "a modest proposal" refers to?

No, but I'm sure that this will be a Great Leap Forward.

---

From: Dean Willis <[email-masked]>
Date: Tue, 22 Jan 2013 22:01:29 -0600

On Mon, Jan 21, 2013 at 10:57 PM, William Jordan <[email-masked]> wrote:

> Whoever thought it was a good idea to allow multiple ways of doing the same
> exact thing would hopefully be deterred by actually writing code to do it.
> I think a suitable punishment for those people would be to write each way of
> writing a from header on a blackboard 100 times... this would actually be
> less of the pain they've cause by making each writer of a SIP stack handle
> each possible way of doing things.

I know this because I chaired the meetings for the RFC 2543 to RFC
3261 re-write. It's even worse than you think; half of the
participants were hard-core coders, each of whom had done an
implementation (or two). The other half were philosophy or art
students, who wanted the spec to be beautiful and meaningful and true
and formally correct and all those good things. And EVERYBODY had a
conflicting understanding for what they wrote, mostly based on
fondling a different part of the elephant. I was just lazy and tried
to keep from having to rewrite too much code due to spec changes,
except of course for that parts that were totally bogus (like strict
routing).

It's called a "committee" for a reason. That's where one gets
two-headed llamas and the US federal budget. Oh wait, we don't have a
budget yet, going on three years.

--
Dean

---

From: joel jaeggli <[email-masked]>
Date: Tue, 22 Jan 2013 20:14:41 -0800

On 1/22/13 12:34 AM, Hannes Tschofenig wrote:
> Another example from a different area: Why do we need so many 
> transition technologies for the migration from IPv4 to IPv6? Wouldn't 
> it be less complex to just have one transition mechanism?

You mean no transition mechanisms...

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Jan 2013 07:58:40 +0000

> You mean no transition mechanisms...

That was, in fact, the plan (dual stack during coexistence).
It went wrong.

  Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Jan 2013 11:27:17 +0200

Hi Brian, Hi Joel, 

the point of my mail was not to start a discussion about the examples I provided but to note that the suggested "let's reduce complexity by reducing options" is not as easy as it sounds in practice.

In the context of the document Stephen wrote and the proposal that was made on the list I was wondering whether a bit more analysis about what the problems we are trying to solve would be helpful. As some folks had raised implementing specifications is not a sufficient condition for interoperability, or successful deployment. I personally believe that IETF working groups are a fine job in writing code along with their specification work. 

Ciao
Hannes

---

From: joel jaeggli <[email-masked]>
Date: Wed, 23 Jan 2013 09:00:56 -0800

> the point of my mail was not to start a discussion about the examples I provided but to note that the suggested "let's reduce complexity by reducing options" is not as easy as it sounds in practice.
The prototypical human enterprise has need to innovate which means 
finding a way to bring products and services which people want buy to 
market. This process is both one of discovery and failure (market 
signals). Part of the process which respond(s) in an inverse fashion to 
market signals is effort required for standardization (e.g. increased 
demand and therefore resources makes it harder not easier). It is is 
relativity easy at the margins to wing documents for things which nobody 
really cares about through the IETF (one can contrast this with other 
standardization processes if you like), the result being that you have a 
record of a diversity of lightly used but possibly important to someone 
or potentially no-one solutions. When you have a great number of groups 
involved in the development of what is currently a hot area of work, the 
amount of effort associated with getting those drafts through a  process 
is dramatically larger, they are subject to evolutionary pressure, and 
they have to satisfy the needs of a great number of constituents, that 
probably if not always produces a better outcome as far as utility, and 
interoperability as concerned but the efforts at the margins don't stop 
because of it.

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 23 Jan 2013 17:59:34 -0500 (EST)

A great deal of complexity comes from the fact that standards are
rarely created in a vacuum.

In this case, RFC 3261 SIP had to be upward-compatible from RFC 2543
SIP.  And the early design of RFC 2543 SIP was influenced (I am told)
by the idea that SIP messages should be able to go through HTTP
proxies.  (That didn't work out, but the idea is less silly than it
seems, especially if you are contemplating organizations whose only
permitted outside net traffic goes through HTTP proxies...)

So, much of the SIP header formatting was taken from HTTP, which got
it from RFC 822 e-mail message formatting.  And of course, once a
variation is permitted, you *can't take it out*, because some product
with significant market share depends on it.

There is also the necessity to allow for extensibility, which favors
the use of various sorts of separators rather than a fixed sequence of
fixed-length fields.

As for CR-LF, that is conformity to the ASCII standard by RFC 822,
where "CR" stands for "carriage return" and "LF" stands for "line
feed".  Exactly why those functions were given separate control
characters I don't know, but I suspect it was to allow overstriking.
The CF-LF standard was largely followed back in 1982, especially in
Digital Equipment Corporation systems, which were the backbone of the
Arpanet.  So CR-LF remains the conventional line ending in Internet
protocols.  The use of LF alone seems to come largely from the Unix
lineage of systems.

There is also a strong tendency to favor protocols that are readable
and writable by humans as text strings (among other things, that makes
debugging easier), so formatting alternatives are added to make those
tasks easier.

Dale