Skip to Content.
Sympa Menu

microid - Re: [Microid] Augmented Backus-Naur Form Scheme issues?

microid AT lists.ibiblio.org

Subject: Microid mailing list

List archive

Chronological Thread  
  • From: Peter Saint-Andre <stpeter AT jabber.org>
  • To: Brian Suda <brian.suda AT gmail.com>
  • Cc: microid AT lists.ibiblio.org
  • Subject: Re: [Microid] Augmented Backus-Naur Form Scheme issues?
  • Date: Tue, 14 Aug 2007 15:44:45 -0600

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




Archive powered by MHonArc 2.6.24.

Top of Page