Rendering of URI samples

[mpotter@…]

While trying to document a sample SIP URI I found I could not simply italic the variable part of the URI. On further experimentation I found this seams to affect any scheme:hier-part URIs. The obvious escaping of the scheme tag did no resolve the issue.

Examples:

 * sip:N''access-code''@192.168.0.20
 * !sip:N''access-code''@192.168.0.20
 * mailto:Subscribe-''conference''@192.168.0.10
 * !mailto:Subscribe-''conference''@192.168.0.10
 * ftp://ftp.domain.com/''path''/''file''
 * !ftp://ftp.domain.com/''path''/''file''

Gives:

• sip:N''access-code''@192.168.0.20
• sip:N''access-code''@192.168.0.20
• mailto:Subscribe-''conference''@…
• mailto:Subscribe-''conference''@192.168.0.10
• ​ftp://ftp.domain.com/''path''/''file
• ftp://ftp.domain.com/''path''/''file

Work-around: Use the monospace markup to avoid the processing of the scheme, example:

 * `sip:N`''access-code''`@192.168.0.20`
 * `mailto:Subscribe-`''conference''`@192.168.0.10`
 * `ftp://ftp.domain.com/`''path''`/`''file''

Gives:

• sip:Naccess-code@192.168.0.20
• mailto:Subscribe-conference@192.168.0.10
• ftp://ftp.domain.com/path/file

[Christian Boos]

Yes, this happens because we first match sip:N''access-code''@192.168.0.20 as a link, then we reject it as sip is not a known protocol. Same happens when the link is "escaped" with !, it's first recognized as a whole. You can see that effect on the ftp: and mailto: links.

Having a kind of recursive parsing for the rejected text and trying other patterns but the one that failed seem difficult to implement efficiently. So workarounds like the one you found seems to be the only realistic approach for now.

But I'm interested to hear suggestions.

[Mark Potter <mpotter@…>]

A similar problem comes up in the standard C parser. Take for example the line:

x = (foo)-(bar);

The basic lexical analyzer sees this as:

IDENTIFIER '=' '(' IDENTIFIER ')' '-' '(' IDENTIFIER ')' ';'

However that could be parsed two different ways, either

variable assignment_operator variable minus variable

or

variable assignment_operator type_cast negative variable

The way this is typically resolved is the parser maintains a type-definition table and then the lexical analyzer checks this table for each possible IDENTIFIER returning either IDENTIFIER or TYPE_NAME to the parser.

With that in mind I would think that this could be better handled if the parser could recognize the valid URL prefixes up front. Alas this would only work for the sip: case, since Trac currently does not support this prefix, but would not for the mailto: or ftp: cases.

The only other solutions I can think of are:

• Add some sort of new scope limiting syntax.

  {sip:N}''access-code''@192.168.0.20
  {mailto:}Subscribe-''conference''@192.168.0.10
  {ftp:}//ftp.domain.com/''path''/''file''
  

• Utilize the already existing square-bracket as a scope limiter. Basically making [! a special case.

  [!sip:N]''access-code''@192.168.0.20
  [!mailto:]Subscribe-''conference''@192.168.0.10
  [!ftp:]//ftp.domain.com/''path''/''file''
  

[Mark Potter <mpotter@…>]

Replying to Mark Potter <mpotter@…>:

• Utilize the already existing square-bracket as a scope limiter. Basically making [! a special case.

I was thinking that '[' and ']' were not valid characters in a URL. However looking at the ​grammar in ​RFC3986 it appears that they can in the host as a way to specify an IPv6 address.