Re: [art] Revising BCP56: On the use of HTTP as a Substrate

[Ted Hardie <[e-mail]>]

On Sat, Jul 15, 2017 at 4:09 PM, Mark Nottingham <[e-mail]> wrote:

>
> > On 15 Jul 2017, at 11:20 am, Adam Roach <[e-mail]> wrote:
> >
> > I found 4.3.2 particularly interesting, as there doesn't seem to have
> been consensus in this space in the past. For example, the ws(s) and ipp(s)
> schemes made a different decision. I presume your assertion is that, were
> we defining these protocols today, they would be using http(s) instead?
>
> AFAICT IPP doesn't use the HTTP port, scheme nor HTTP's registries, so as
> per section 2, it's not "using" HTTP.
>
>
RFC 7472 describes the  HTTPS tranport binding and its relationship to the
ipps scheme (it's a successor to some previous work doing similar things
for HTTP).  It notes:

The IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230
<https://tools.ietf.org/html/rfc7230>]
      (replacing 'ipps' with 'https' and inserting the port number from
      the URI or port 631 if the URI doesn't include an explicit port
      number);

While the default isn't the existing HTTPS port, it's my understanding that
in some deployments the ipps scheme uses the HTTPS port and so ends up with
an HTTPS scheme message over the standard HTTPS port.

regards,

Ted


> WS(S) uses port 80/443 to bootstrap into another protocol (using Upgrade).
> There probably needs to be a carve-out for that.
>
> > I don't see anything wrong with that; I just want to probe the edges of
> this advice by seeing how it would have applied to decisions we made in the
> past, since that's a pretty good predictor for how it might apply in the
> future.
> >
> > The advice in 4.3.3 seems a bit strong, in that it will require whatever
> process listens on port 443 to take on an ever-increasing role. If we're
> going to keep this advice, I think the document needs some treatment of the
> software architecture implications: functionally, whatever listens to port
> 443 will need to be able to delegate sub-trees of the URL space to other
> processes. I know that some web servers have mechanisms to handle this kind
> of thing today; but we're effectively saying that this will become required
> base functionality for web servers moving forward.
> >
> > I wonder, in that context, whether the current advice strikes the right
> balance.
>
> I think that's a great conversation to have.
>
> Cheers,
>
> >
> > /a
> >
> > On 7/11/17 06:14, Mark Nottingham wrote:
> >> A number of folks have recently noted that BCP56 addresses the problems
> of using HTTP for protocols in the early 2000's, but we've moved on
> considerably since then.
> >>
> >> Given the number of IETF protocols being build upon HTTP these days, it
> seems timely to reconsider it. I've been working on a candidate for
> replacing it for a little while; see:
> >>   https://tools.ietf.org/html/draft-nottingham-bcp56bis
> >>   https://mnot.github.io/I-D/bcp56bis/
> >>
> >> I have a small-ish slot in the HTTP WG session on Wednesday to discuss
> this.
> >>
> >> Cheers,
> >>
> >> --
> >> Mark Nottingham   https://www.mnot.net/
> >>
> >> _______________________________________________
> >> art mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/art
> >
> >
> > _______________________________________________
> > art mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/art
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
> _______________________________________________
> art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/art
>