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 discus
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
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 interoperabil
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 int
> "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. Features and options of protocols
need to be testable.
___
Ie
> "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
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
> "Robert" == Robert Sayre <[EMAIL PROTECTED]> writes:
Robert> On 9/6/06, Keith Moore 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 reso
On 9/6/06, Keith Moore 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 resources a
> On 9/6/06, Keith Moore 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 th
On 9/6/06, Keith Moore 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 deployments, like
som
> 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 o
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 tr
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 Intern
On 9/6/06, Keith Moore 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 result of
bureau
11:36 AM
> To: Robert Sayre
> Cc: Sam Hartman; ietf@ietf.org
> 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.
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
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 pr
> "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 prett
> "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 H
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 severa
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
draft-carpenter-rfc2026-cr
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 st
> "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 pro
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
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
> "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
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 application protocol.
I worry that such text will encourage sprawling specifi
Sam,
this question is important and interesting.
IMHO there are two different types of interoperablities, which in
turm makes billions of them: you have interoperability (direct plug)
and metainteroperablity (the current through the plug can
interoperate through a converter when the plugs ar
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 2026
30 matches
Mail list logo
