HTTP(s) URI scheme definitions

[mnot@…]

The HTTP and HTTPS (if taken on board) URI schemes need to clearly state their restrictions, in particular;

• what an empty host means (error - see #92)
• the status of userinfo (disallowed?)

etc.

[mnot@…]

As per Roy (in discussing #128):

We are going to define the https scheme in part 1 because the syntax needs to be updated along with the http scheme. RFC 2818 is a dead duck.

[fielding@…]

From [621]:

Define http and https URI schemes: addresses #58, #128, #159 Resolves #157: removed reference to RFC1900 use of IP addresses in URI.

[fielding@…]

Did first part in [621]. I will add statement about userinfo somewhere.

[mnot@…]

Discussed at Stockholm WG meeting. Feeling in the room: no empty authority, don't allow userinfo.

[fielding@…]

From [877]:

Addresses #159: HTTP(s) URI scheme definitions

Make clear that userinfo is not allowed. Clarify the differences between "http" and "https".

[julian.reschke@…]

From [881]:

Note change in [877] relating to issue 159 (see #159)

[julian.reschke@…]

From [963]:

update status of issue 159 as work in progress (see #159)

[julian.reschke@…]

I really think we should have registration templates in the IANA Considerations section.

[fielding@…]

From [1157]:

Discussion on list suggests that userinfo remains in common use for configuration or command options, so it needs to be defined. However, we can exclude it from being sent in messages.

Addresses #159

[fielding@…]

I don't see any value in including IANA templates for these two URI schemes that are already defined on the standards-track (templates primarily provide IANA with change control information). Can we close this now?

[julian.reschke@…]

+1 to close. I may want to check later on that we actually *have* all the information that's required by the registration template, but if we don't we can treat that as separate issues.

[julian.reschke@…]

From [1159]:

note change [1157], see #159