Re: port #?

Or we could say that URIs which map to the use of HTTP/1.1 would map to the
use of HTTP/2.0 without change and not mention any parts of it specifically.
-=R


On Fri, Jun 7, 2013 at 1:30 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> Everything that Ted says, plus I think that the suggested text isn't
> quite the right place.  We talk about using the same "http:" and
> "https:" schemes in Section 2.  It would be relatively easy to add
> "...and ports" to the following statement:
>
> OLD:
>    HTTP/2.0 uses the same "http:" and "https:" URI schemes used by
> HTTP/1.1.
> ADD:
>    HTTP/2.0 also shares the same default port numbers: 80 for "http:"
> URIs and 443 for "https:" URIs.
>
> That would address option 5, remove any ambiguity, etc...
>
> On 7 June 2013 13:17, Ted Hardie <ted.ietf@gmail.com> wrote:
> > Hi Eliot,
> >
> > Some comments in-line.
> >
> >
> > On Fri, Jun 7, 2013 at 1:02 AM, Eliot Lear <lear@cisco.com> wrote:
> >>
> >>
> >> Hi everyone,
> >>
> >> I note that we still haven't cleaned up the connection model
> >> sufficiently.  When someone implements a specification they need to know
> >> at least the port number to connect to. This is the document that has to
> >> specify at least at a bare minimum how that happens.  This can be
> >> handled in at least one of four ways:
> >>
> >> 1.  We refer to RFC-2616 normatively.  This implies that we will not
> >> obsolete 2616 at this time.  If we do so later we would need to pull the
> >> HTTP URI definition out and update the IANA definition.
> >
> >
> > Other httpbis documents obsolete 2616, so we should refer to those,
> rather
> > than 2616.
> >
> >>
> >> 2.  We pull the HTTP URI definition out and produce a small document for
> >> it separately and refer to that, updating RFC-2616.
> >>
> >> 3.  We include the URI definition in the HTTP2 draft.
> >
> >
> > If it needs to be re-iterated, I think having the reiteration within the
> > HTTP2 draft is fine.  But simply referring to whatever RFC
> > draft-ietf-httpbis-p1-messaging-13 becomes seems simpler.  That
> reinforces
> > the idea that HTTP2 and HTTP share the same URI synatx.
> >
> >
> >>
> >> 4.  We abstract the connection model entirely from the document.
> >> 5.  We specify that unless specified within a URI, the default protocol
> >> is TCP and the default port is 80.
> >>
> >> This all came to light because of interest to do some work with HTTP2
> >> using something other than TCP.  Thus, one might thing that [4] is the
> >> appropriate thing to do, but my experience with BEEP is that it lends
> >> itself to an ugly set of documents and violates the KISS principle.  To
> >> that end, I recommend the text in [5] be added for now, and that as
> >> HTTP2 matures we consider [2] later.
> >>
> > So, I think saying that new transports may mint new URI schemes
> > (http.newfangled) is safe enough; they may.  But I'm not sure whether
> that
> > adds much value.  What's the harm in simply referring to
> > draft-ietf-httpbis-p1-messaging for the URI syntax and leaving it at that
> > for the moment?
> >
> > regards,
> >
> > Ted
> >
> >
> >>
> >> Specifically, OLD:
> >>
> >>    The HTTP/2.0 session runs atop TCP ([RFC0793]).  The client is the
> >>    TCP connection initiator.
> >>
> >> NEW:
> >>
> >>    Unless otherwise specified within a URI, an HTTP/2.0 session runs
> >>    atop TCP ([RFC0793]) and a client initiates a server on port 80.
> >>
> >> Eliot
> >>
> >
>
>