- changed status to open
Discovery 2.1.1 - Who escapes '@'?
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".
Comments (9)
-
-
Account Deleted - changed status to new
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 '@'.
-
Account Deleted - changed status to open
Sorry, mistake.
-
- changed component to Discovery
-
assigned issue to
- edited description
-
Account Deleted 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.
-
-
assigned issue to
-
assigned issue to
-
New proposal:
-
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.
-
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.
-
All other user input Identifiers MUST be treated as URI relative references.
-
-
Account Deleted Looks reasonable with the change in https://bitbucket.org/openid/connect/changeset/25c8f6dd5c8c
-
- changed status to resolved
- Log in to comment
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.