Server should partially encode Slug header values

Servers MAY allow clients to suggest the URI of a resource created through POST, using the HTTP Slug header as defined in [RFC5023].

— 5.1 Resource Type Heuristics

The value supplied by a caller in the Slug header ends up an being an IRI path segment.
Because of this, implementations must deal with slug characters that would be invalid in a segment.
At least one implementation currently strips invalid characters.

I propose mandating that implementations percent encode offending characters if they honour the slug:

POST /container/
Slug: a/b

HTTP 201
Location: /container/a%2Fb

We should suggest that servers do not encode any other character but the ones illegal in path segments:

POST /container/
Slug: fancy-slug!

HTTP 201
Location: /container/fancy-slug!

The offending class of characters that should be encoded is anything outside of pchar (RFC 3986).

Start with section 5.1, Resource Type Heuristics, and compare its current Slug guidance with RFC 3986 section 3 and the RFC 5023 reference. Done means the specification clearly defines percent encoding for Slug characters outside pchar while leaving allowed characters such as “!” unchanged.