Microid mailing list

[Peter Saint-Andre <stpeter AT jabber.org>]

Brian Suda wrote:
> i did a quick search through the archives and didn´t find anything
> http://www.google.is/search?hl=is&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=Q5N&q=site%3Ahttp%3A%2F%2Flists.ibiblio.org%2Fpipermail%2Fmicroid%2F+scheme&btnG=Leita&lr=
> 
> Can some one confirm that this is not actually an issue, or that it
> doesn´t matter that it is?
> 
> According to the scheme:
> inputs  = scheme "+" scheme
> scheme  = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
>           ; a URI scheme name (e.g., mailto)
> 
> you can have multiple schemes separated by a + symbol, but the scheme
> itself can have a + in it. For example:
> 
> svn+ssh as one scheme, concatenated + with a second scheme, https
> 
> that would be svn+ssh+https, how would you know that is svn+ssh and
> not ssh+http? or is that even an issue?

That is a good catch. Section 3.1 of RFC 3986 defines scheme as follows:

   scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

So you're right that "+" is allowed in the scheme name. Clearly we did
not check the URI syntax when we defined the MicroID syntax, and a quick
check of the IANA registry would have revealed no schemes with "+" in
the name:

http://www.iana.org/assignments/uri-schemes.html

We should have chosen a character that's not allowed in "scheme", such
as "_".

But I'm not sure what to do about it now. We could:

1. Change the separator to "_" or somesuch.

   Pro: Conforms to RFC 3986.
   Con: Breaks existing implementations.

2. Provide guidance for handling of "+".

   Pro: Doesn't break existing implementations.
   Con: Potentially confusing; does not conform to RFC 3986.

The spec writer in me likes (1), but the documentation guy in me prefers
(2) since I really don't like to break existing implementations.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature