RE: weighting transports

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Dave CROCKER [mailto:[e-mail]] 
> Sent: Sunday, April 04, 2010 10:52 AM
> To: Dan Wing
> Cc: [e-mail]
> Subject: Re: weighting transports
> 
> Dan,
> 
> 
> On 4/2/2010 4:47 PM, Dan Wing wrote:
> > The IETF standardized SCTP a decade ago.  We could just add 
> it to the list of
> > 'failures'... or sit and wait and wonder why The Industry 
> has not adopted the
> > technology.
> 
> This is what's called a false dichotomy.  It asserts only two 
> alternatives --
> which can be as arbitrary as these two -- and ignores all the 
> others that are
> available.  It is an expression of frustration used when 
> attempting to terminate 
> debate and prematurely force adoption of one of the 
> alternatives, without 
> consideration of the underlying issues or tradeoffs.
> 
> I now believe the deeper question is persistent validity of 
> URLs, across changes
> to the infrastructure.  For example, should a URL become 
> invalid because a
> different transport is used?
> 
> The answer needs to be no.  Yet the view that the URL scheme 
> would change when a
> new transport is used will produce that unfortunate result.
> 
> It's not that Ted's concern about the possibility of 
> divergent results based on
> using different library packages is wrong, it's that the 
> proposed solution with
> different URIs is clearly the wrong result. 

It sounds like you were reading a -01 (or later) of
draft-jennings-http-srv.  The later versions do propose
a different URI.

However, that was not what I cited. 

Cullen's original proposal (-00) to which Ted (and John) were
commenting, did _not_ have a different URI.  It uses the same
URI.  Cullen's draft-jennings-http-srv-00 was submitted July 5, 
2008 and Ted and John's comments were on July 7.

> Having an 
> application protocol run 
> over a different transport does not create a different 
> service; it should not 
> render the URI invalid.
> 
> I've pushed back on your proposal not because I think you are 
> pursuing an
> unattainable or unproductive goal but because its success has 
> too many critical
> dependencies and too little compelling near-term value for adopters.
> 
> The hard work is in reducing dependencies and increasing 
> perceived value.
> Ignoring barriers to adoption seems to account for the failure of most
> otherwise-appealing efforts.
> 
> The idea that a URI scheme couples application protocol with 
> transport is really
> an architectural form of source-routing.  One of the 
> architectural wins for
> Internet design has been hiding details from upper layers.
> 
> (For that matter, "http://" has this problem for the 
> application layer, whereas
> "mailtto://" does not.  It's the difference between using 
> protocol names versus
> service names. We need to be careful about forcing the wrong 
> set of changes on 
> existing behaviors.)
> 
> 
> As of right now, I'd be interested in a review of the reason 
> SRV records aren't
> perfect dealing with the choice between TCP and SCTP.  I 
> thought that that was 
> the one of the reasons SRVs were created.

Sure, that can easily added to the I-D.

Big difference is that:

  * SRV requires a separate DNS query for each transport 
    a client supports.
  * the earlier proposal to use SRV (draft-jennings-http-srv-00) 
    for HTTP was rejected by Ted Hardie and John Klensin.

-d


> d/
> 
> -- 
> 
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net