Re: port #?

[Eliot Lear <[e-mail]>]

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

Eliot

On 6/9/13 9:40 PM, Mark Nottingham wrote:
> 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,
>
>
> On 08/06/2013, at 5:30 AM, Martin Thomson <[e-mail]> 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 <[e-mail]> wrote:
>>> Hi Eliot,
>>>
>>> Some comments in-line.
>>>
>>>
>>> On Fri, Jun 7, 2013 at 1:02 AM, Eliot Lear <[e-mail]> 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
>>>>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>