Subject: RE: Last Call: 'Procedures for protocol extensions and variations' to BCP (draft-carpenter-protocol-extensions)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 6 Sep 2006 09:04:56 -0700

Keith is as often the case dead wrong.

HTTP works fine over non TCP/IP protocols and the ability to do so was pretty important in 1991 when IP was not considered the one true protocol.

The protocol that IS essential to the working of HTTP is in fact DNS. HTTP and URIs depend upon there being a universal namespace to a much greater extent than the previous generation of protocols. It is possible to run HTTP over DECNET but doing so means that you can only access information on DECNET nodes.

A significant proportion of HTTP traffic takes place over non TCP protocols today. TCP/IP is not optimized as a cell phone transport. There are true IP based browsers on cell phones but they suck really badly. My Palm Treo has the worst browser I have seen in a decade.

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]] 
> Sent: Wednesday, September 06, 2006 11:36 AM
> To: Robert Sayre
> Cc: Sam Hartman; [email-masked]
> Subject: Re: Last Call: 'Procedures for protocol extensions 
> and variations' to BCP (draft-carpenter-protocol-extensions)
> 
> >> I want to be able to give you a URL and have you resolve it.  That 
> >> only works if we speak the same transport protocol.
> > 
> > Disagree. The Internet is pretty compelling, so proxies can and do 
> > bridge transport protocols. Applications using the HTTP stack don't 
> > need to know or care about the lower level.
> 
> Disagree.  HTTP proxies do exist but the only reason that 
> they can work effectively is that the vast majority of web 
> resources are accessible through a common medium - namely the 
> public IPv4 Internet and TCP.  If the web were split across 
> several networks with dissimilar characteristics, it would be 
> much more difficult to arrange seamless access via proxies.
> 
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Sep 2006 14:20:45 -0400

> Keith is as often the case dead wrong.

Phill, when you criticize me, it only serves to enhance my reputation. :)

> HTTP works fine over non TCP/IP protocols and the ability to do so was pretty important in 1991 when IP was not considered the one true protocol.

Yes, HTTP can work fine over other transports.    That is however of
little relevance to the fact that the vast majority of the web's
content is only accessible via IPv4 and TCP.  Imagine a not-too-distant
world, where there is a significant set of resources accessible only
through TCP/IPv4, another set accessible only via TCP/IPv6, and another
set accessible via either.  In such a world a significant portion of
the web's resources would not be accessible by any client that didn't
have access to both IPv4 and IPv6, except via a proxy.  Proxies could
and probably would be set up, but experience seems to indicate that
there are enough problems with providing for and locating such proxies
to make them seem less than viable as a general solution.

> A significant proportion of HTTP traffic takes place over non TCP protocols today. 

yes, but only as a client-to-proxy protocol.  you won't find many web resources
hosted on cell phones.

Keith

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 6 Sep 2006 14:28:12 -0400

> yes, but only as a client-to-proxy protocol.  you won't find many web resources

This is true, but there are many other non-TCP HTTP deployments, like
some of the "content delivery" technology that's out there.

I think we're off on a tangent. Requiring TCP wouldn't change any of
the realities we're discussing, so it's not a bug in the HTTP spec.

-- 

Robert Sayre

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Sep 2006 15:07:59 -0400

>>>>> "Robert" == Robert Sayre <[email-masked]> writes:

    Robert> On 9/6/06, Keith Moore <[email-masked]> wrote:
    >> yes, but only as a client-to-proxy protocol.  you won't find
    >> many web resources hosted on cell phones.

    Robert> This is true, but there are many other non-TCP HTTP
    Robert> deployments, like some of the "content delivery"
    Robert> technology that's out there.

    Robert> I think we're off on a tangent. Requiring TCP wouldn't
    Robert> change any of the realities we're discussing, 

Agreed.

    Robert> so it's not
    Robert> a bug in the HTTP spec.

Not at all obvious to me.

    Robert> --

    Robert> Robert Sayre

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 6 Sep 2006 15:29:31 -0400

> Not at all obvious to me.

It's not obvious to me why we would to change the concrete definition
of interoperability in RFC2026 to an *untestable* definition that has
no bearing on reality, and do it in a document about protocol
extensions.

IMHO, an untestable definition of interoperability places too much
power in the hands of individuals. One can already claim that
something *really* fractious will harm the Internet, so a nebulous
definition of interoperability doesn't seem necessary.

-- 

Robert Sayre

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Sep 2006 15:55:11 -0400

>>>>> "Robert" == Robert Sayre <[email-masked]> writes:

    Robert> It's not obvious to me why we would to change the concrete
    Robert> definition of interoperability in RFC2026 to an

I don't think anyone is proposing changing the definition: For the
purposes of this section, "interoperable" means to be functionally
equivalent or interchangeable components of the system or process in i
which they are used.

I think we are discussing consequences of that definition that are
non-obvious.  RFC 2026 requires that two interoperable implementations
exist.  However I believe that there is a strong IETF consensus that
our specs need to support universal interoperability.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Sep 2006 16:13:15 -0400

>>>>> "Robert" == Robert Sayre <[email-masked]> writes:

    Robert> How do we test "universal interoperability"? MUSTs need to
    Robert> be testable.

Musts do not need to be testable.  Features and options of protocols
need to be testable.

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 6 Sep 2006 15:59:57 -0400

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 6 Sep 2006 15:59:57 -0400

> our specs need to support universal interoperability.

How do we test "universal interoperability"? MUSTs need to be testable.

And why would we put the definition in Brian's document?

-- 

Robert Sayre

xt/plain; charset=ISO-8859-1; format=flowed
Cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Last Call: 'Procedures for protocol extensions and variations'
	to BCP (draft-carpenter-protocol-extensions)

> our specs need to support universal interoperability.

How do we test "universal interoperability"? MUSTs need to be testable.

And why would we put the definition in Brian's document?

-- 

Robert Sayre

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 6 Sep 2006 16:22:21 -0400

On 9/6/06, Sam Hartman <[email-masked]> wrote:
> Musts do not need to be testable.

So the definition of "supports universal interoperability" is "I know
it when I see it"? Which IETF protocols are universally interoperable?
I think of SMTP and HTTP.

I also asked you two questions. Here is the second:

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 6 Sep 2006 16:53:32 -0400

> And why would we put the definition in Brian's document?

Er, my private mail tells me this message might have seemed incredibly
offensive to someone who has attended an IETF meeting (I have not).
Let me rephrase my objections as follows:

1.) How can such a nebulous definition be acceptable?
2.) Why this document?

-- 

Robert Sayre

---

From: Jefsey_Morfin <[email-masked]>
Date: Thu, 07 Sep 2006 01:30:00 +0200

>our specs need to support universal interoperability.

Oouhaou!

are:
- functionally _equivalent_
- interchangeable
- universal interoperability
supposed to be the same concept?
At the same layers?
jfc

>our specs need to support universal interoperability.

Oouhaou!

are:
- functionally _equivalent_
- interchangeable
- universal interoperability
supposed to be the same concept?
At the same layers?
jfc