Template restrictions

[mnot]

Client config says:

• The URI Template MUST NOT use Reserved Expansion ("+" operator), Fragment Expansion ("#" operator), Label Expansion with Dot-Prefix, Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Semicolon-Prefix.

I understand why fragment expansion is undesirable, but the rest of these seem pretty arbitrary. How does this requirement improve interoperability?

[DavidSchinazi]

The intent here was to safely simplify client implementations. It improves interoperability by avoiding failures when clients don't implement these unnecessary expansions but proxy deployments use them. We would have preferred to use a Level 1 template, but there was interest in using query parameters. Unfortunately I'm not aware of a clean way to do that without the mix-and-match approach that's currently in the document.

[mnot]

Hm. What's weird is that an off-the-shelf uri template parser may not be able to easily expose this information, so you're requiring clients to write more bespoke code to conform to these requirements.

[DavidSchinazi]

The requirement here applies to the configuration, not to the parser. Clients that use a full off-the-shelf level 3 (or higher) parser are spec compliant here since they'll be able to parse any template that follows those requirements. Would adding a comment saying as much address your concern here?

[DavidSchinazi]

I've cleaned up the client validation text in b01260aac236f161f8faf5f5a00f352b0716c8e4

[mnot]

That addresses my concern, thanks.