Subject: port #?

From: Eliot Lear <[email-masked]>
Date: Fri, 07 Jun 2013 10:02:03 +0200

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.
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.
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.

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 07 Jun 2013 10:36:26 +0200

> HTTP URI definition out and update the IANA definition.

Hm, no. draft-ietf-httpbis-p1-messaging is what's relevant (and should 
stay relevant).

> ...

Best regards, Julian

---

From: Eliot Lear <[email-masked]>
Date: Fri, 07 Jun 2013 11:10:00 +0200

Julian,

Right you are.  So... propose some text?

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Fri, 7 Jun 2013 13:17:02 -0700

Hi Eliot,

Some comments in-line.

> HTTP URI definition out and update the IANA definition.

Other httpbis documents obsolete 2616, so we should refer to those, rather
than 2616.

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.

> 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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Jun 2013 13:30:11 -0700

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...

---

From: Roberto Peon <[email-masked]>
Date: Fri, 7 Jun 2013 13:33:31 -0700

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 10 Jun 2013 10:40:16 +0900

Fine by me, as long as people don't (yet) read this as precluding using another port if we have external, non-URI information (e.g, a DNS record).

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Jun 2013 04:55:13 -0400

It's fine by me too.  So would be referencing
draft-ietf-httpbis-p1-messaging, as Julian suggests.

Eliot