Discovery 2.1.1 - Who escapes '@'?

[Former user]

I thought about extending this spec to URI contains '@' (ex. XMPP URI) and could not figure out who escapes '@' in URI. End-users may enter URIs containing '@'s without replacing them with "%40".

[Michael Jones]

2.1.1 Currently says "2.Any Identifier that contains the '@' character in any position other than the first position MUST be treated as an e-mail address.", so this would require a change.

We could look for a scheme first, which would allow xmpp URIs.

The working group would be interested in a proposed change.

[Former user]

If "scheme" and ":"

ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) ":"

is at the beginning of the input string, I think it should be treated as URL even if it contains '@'.

[Former user]

Sorry, mistake.

[Former user]

I propose the following contents for the "2.1.1 Identifier Type" section.

2.1.1 Identifier Type

1. (same as the current version)

2. Any Identifier that contains the ':' character in any position and the substring before that ':' character matches the "scheme" syntax of RFC 3986 [RFC3986] MUST be treated as a URL.

3. All other Identifiers that contains '@' character in any position other than the first position MUST be treated as e-mail addresses.

4. All other Identifiers MUST be treated as URLs.

[Nat Sakimura]

New proposal:

1. User input Identifiers starting with the XRI [XRI_Syntax_2.0] global context symbols ('=','@', and '!') are RESERVED. Processing of these identifiers is out of scope for this specification.

2. Any Identifier that contains the ':' character in any position and the substring before that ':' character matches the "scheme" syntax of RFC 3986 [RFC3986] MUST be treated as a URL.

3. All other user input Identifiers MUST be treated as URI relative references.

[Former user]

Looks reasonable with the change in https://bitbucket.org/openid/connect/changeset/25c8f6dd5c8c