On 9/5/06, Sam Hartman [EMAIL PROTECTED] wrote:
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
Sam gave me a heads up this comment was coming (on the last day
of the Last Call, as it happens) so I had the chance to think about
it overnight.
We certainly could use clarity in this area. I also have some comments
about the meaning of interoperable implementations in
At 05:52 06/09/2006, Sam Hartman wrote:
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.
I want people to be able to reference HTTP and get interoperability,
not to have to write a profile of http.
Sam,
there are several ways
Jefsey == Jefsey Morfin [EMAIL PROTECTED] writes:
Jefsey At 05:52 06/09/2006, Sam Hartman wrote:
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.
I want people to be able to reference HTTP and get
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert On 9/5/06, Sam Hartman [EMAIL PROTECTED] wrote:
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.
Robert Disagree. The Internet is pretty compelling, so
On 9/6/06, Sam Hartman [EMAIL PROTECTED] wrote:
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert On 9/5/06, Sam Hartman [EMAIL PROTECTED] wrote:
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.
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
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
On 9/6/06, Keith Moore moore@cs.utk.edu wrote:
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.
Right. But that is a natural occurrence, not the
At 17:35 06/09/2006, Keith Moore wrote:
If the web were split across several networks with dissimilar
characteristics, it would be much more difficult to arrange seamless
access via proxies.
The if is the reality. Forgetting about it does simplifies things.
This is like computing the
At 15:30 06/09/2006, Sam Hartman wrote:
Jefsey - either you consider the Internet as Harald Alvestrand
Jefsey considers it in RFC 3935: something the IETF leaders
Jefsey influence the building along their values. This vision is
Jefsey OK with me as long as this Internet is one system among
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
On 9/6/06, Keith Moore moore@cs.utk.edu wrote:
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.
This is true, but there are many other non-TCP HTTP
On 9/6/06, Keith Moore moore@cs.utk.edu wrote:
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.
Right. But that is a natural occurrence,
On 9/6/06, Keith Moore moore@cs.utk.edu wrote:
Of course it's useful to be able to run SMTP, HTTP, etc. over other
transports for special purposes. But a distinction needs to be made
between SMTP specification and how to send Internet email, and
between HTTP specification and how to make web
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert On 9/6/06, Keith Moore moore@cs.utk.edu wrote:
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
On 9/6/06, Sam Hartman [EMAIL PROTECTED] wrote:
Robert == Robert Sayre [EMAIL PROTECTED] writes:
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
Robert == Robert Sayre [EMAIL PROTECTED] 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
On 9/6/06, Sam Hartman [EMAIL PROTECTED] wrote:
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
On 9/6/06, Sam Hartman [EMAIL PROTECTED] wrote:
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert How do we test universal interoperability? MUSTs need to
Robert be testable.
Musts do not need to be testable.
So the definition of supports universal interoperability is I know
On 9/6/06, Robert Sayre [EMAIL PROTECTED] wrote:
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:
And why would we put the
At 21:55 06/09/2006, Sam Hartman wrote:
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
So, I was reading Brian's draft and I noticed that it talks a lot
about interoperability, but does not actually define interoperability.
As discussed in a recent IESG appeal, it's not clear that we have a
clear statement of our interoperability goals. There's some text in
section 4 of RFC
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert On 9/5/06, Sam Hartman [EMAIL PROTECTED] wrote:
There are a lot of complexities--for example while we hope
every IP stack works with every other IP stack, two machines
may not share a common upper-layer protocol or
At 21:56 05/09/2006, Sam Hartman wrote:
To be clear, I think I'm documenting what is a long-standing consensus
in the IETF.And I do consider it a bug that HTTP does not require
TCP.It's typical for protocols to require a transport.For example
, I believe SIP requires UDP (and possibly
Sam Hartman wrote:
[definition of interoperability]
As discussed in a recent IESG appeal, it's not clear that
we have a clear statement of our interoperability goals.
There's some text in section 4 of RFC 2026, but we seem to
actually want to go farther than that text.
[...]
If people
Jefsey == Jefsey Morfin [EMAIL PROTECTED] writes:
Jefsey At 21:56 05/09/2006, Sam Hartman wrote:
To be clear, I think I'm documenting what is a long-standing
consensus in the IETF. And I do consider it a bug that HTTP
does not require TCP. It's typical for protocols to
A couple of nits:
s3: It might be helpful to make the first three paras into a bulleted
list and add an introductory sentence like:
'There are various ways in which an extension to an IETF can be
introduced into the IETF:'
s3, para 3: If my understanding is correct, a document from the
28 matches
Mail list logo
