Rolf-Jürgen Moll | 14 Dec 18:04 2014

Update: provisional URI scheme 'ln' registration


please see below an updated version of the registration template.

I 'd like to stay with the URI scheme name "ln" as it fits the requirements of RFC 4395's Section 3 for
provisional URI scheme registration:

- It meets the syntactical requirements of Section 2.8.
- There is not already an entry with the same URI scheme name.

There are some provisional URI schemes registered which are made up of only two characters: aw, gg.

URI scheme name


URI scheme syntax

URI scheme semantics
(Continue reading)

Rolf-Jürgen Moll | 12 Dec 12:35 2014

provisional URI scheme 'ln' registration

Please review and register this provisional URI scheme template:

URI scheme name


URI scheme syntax

URI scheme semantics
The scheme is used to identify resources provided by the LucaNet.Server.

Allowed values are "http" and "https".

(Continue reading)

Constantine Kousoulis | 22 Aug 00:53 2014

Register 'vmrc' URI scheme


This is a request for a new URI scheme: "vmrc"
Attached as "uri-scheme.txt" is a registration template for this proposal, completed as per RFC 4395.

For more information, please contact me: ckousoulis <at>

Thank you,
Constantine Kousoulis
Resource Identifier (RI) Scheme name: vmrc
Status: provisional

URI scheme syntax.
   vmrc://[<user>|(<ticket-type>:<ticket>) <at> ]<host>[:<port>][/[<path>][?<object-type>=<object-id>][&[...]]
   example: vmrc://username <at> vsphere-server/
   example: vmrc://clone:ticket <at> vsphere-server/?moid=42
   example: vmrc://vcloud-server/urn:vcloud:vm:42

URI scheme semantics.
   Access an object (like a virtual machine) located in a virtual environment (like VMware vSphere).

Encoding considerations.
   Unknown, use with care.

Applications/protocols that use this URI scheme name.
   VMware Remote Console:

Interoperability considerations.
(Continue reading)

Re: Review request for Anonymous Customer Reference (acr:) URI scheme

Hi Graham,

Thanks again for your comments.

Together with the co-authors at OMA, I have rewritten the grammar section to take your advice into account.
While doing this, we have also discovered and fixed some bugs.

The updated document can be found

Kind regards,

> -----Original Message-----
> From: ext Graham Klyne [mailto:gk <at>]
> Sent: Sunday, July 13, 2014 10:42 AM
> To: Rauschenbach, Uwe (NSN - DE/Munich)
> Subject: Re: [Uri-review] Review request for Anonymous Customer
> Reference (acr:) URI scheme
> On 11/07/2014 14:25, Rauschenbach, Uwe (NSN - DE/Munich) wrote:
> >> I'm not sure how useful this scheme would be in practice.
> >
> > UR: If one takes actual use as an indicator of usefulness - the scheme
> is used in ~20 OMA RESTful Network APIs,
> > the GSMA OneAPI, and the GSMA RCS APIs.
> >
> > The basic problem this scheme tries to solve is that (telephone)
> network operators want to hide the actual telephone number
(Continue reading)

Michael Thornburgh | 4 Aug 20:57 2014

review request for provisional URI scheme "rtmfp"

i would like to register URI scheme "rtmfp" in the provisional registry.  in accordance with RFC 4395, i
request review of this request.  the registration template is the IANA Considerations section of
draft-thornburgh-rtmfp-flash (Section 6.1 of draft-thornburgh-rtmfp-flash-05, which is the
current revision).  for convenience, the request template is also reproduced below.

thank you.

-michael thornburgh
 author, draft-thornburgh-rtmfp-flash

   The syntax and semantics of this URI scheme are described using the
   Augmented Backus-Naur Form (ABNF) rules from RFC 3986.
   The term "this memo" means draft-thornburgh-rtmfp-flash.

   URI scheme name:  rtmfp

   Status:  provisional

   URI scheme syntax:

      rtmfp-uri-scheme = "rtmfp:"
                       / "rtmfp://" host [ ":" port ] path-abempty

   URI scheme semantics:  The first form is used in the APIs of some
      applications to indicate instantiation of an RTMFP client
      according to this memo, but without connecting to a server.  Such
      an instantiation might be used for pure peer-to-peer

(Continue reading)

Ben Beltran | 7 Jul 18:18 2014

Request for Provisional URI Scheme recordit


I would like to submit a request for a provisional URI scheme. The request is located here:

Thank you

Ben Beltran

Uri-review mailing list
Uri-review <at>
Ben Beltran | 27 Jun 18:10 2014

Re: Confirm: uri-review <at>

another, huh...

Ben Beltran

On Tuesday, June 24, 2014 at 8:08 AM, uri-review <at> wrote:

Confirmation of list posting -- confirmation ID: U6l4YA7NdPYR

The mailing-list server has received a list posting from
'Re: Confirm:

As the sender address isn't subscribed to the list, and has not been
confirmed earlier, we have to request a confirmation of the address.
To confirm the address, send a message to uri-review <at>,
with the same subject line as this message.

(Simply sending a 'reply' to this message should work from most email
interfaces, since that usually leaves the subject line in the right
form. The reply's additional "Re:" is ok.)

If you do not wish your posting to the list to go through, simply
disregard this message. Questions to postmaster <at>

Uri-review mailing list
Uri-review <at>
Daniel Pocock | 7 May 09:10 2014

registration request for "call:" URI prefix

URI scheme name call - The call: URI scheme can be used to refer to radio callsigns. "call:" does not imply an action, it is used as a noun in this context. Status Provisional URI scheme syntax The parameter is a callsign, e.g. for amateur radio call signs: call:vk3tqr call:M0GLR URI scheme semantics As per the ITU recommendations[1] Encoding considerations Only ASCII alphanumeric symbols are permitted. Case insensitive. Applications/protocols that use this URI scheme name Morse code Interoperability considerations TBD Security considerations None. Contact Daniel Pocock, daniel <at> Author/Change controller Daniel Pocock, daniel <at> References 1.
Uri-review mailing list
Uri-review <at>
Gerardo Capiel | 27 Apr 08:35 2014

Registration request for math: URI scheme

Hi, I'm requesting a provisional 'math' URI scheme name. The 'math' URI scheme and protocol handler can be used by Web browsers and other applications to transport mathematical expressions to other applications, such as Assistive Technologies or graphing calculators. Below is the provisional URI Scheme Registration Template: URI scheme name math - The math: URI scheme can be used by Web browsers and other applications to transport mathematical expressions to other applications, such as Assistive Technologies or graphing calculators. Status Provisional x URI scheme syntax Applications launched via the math protocol take as a parameter either a URL to a resource containing a mathematical expression in MathML or other formats or the actual math expression in uncompressed or compressed form. For example: math:// math:<math><mi>x</mi><mo>+</mo><mn>2</mn></math> math:<math-compressed>someexpressionincompressedformat</math-compressed> URI scheme semantics TBD Encoding considerations TBD Applications/protocols that use this URI scheme name Applications should register the math: protocol handler with this scheme. Interoperability considerations TBD Security considerations None known. Contact Gerardo Capiel, gcapiel <at> Author/Change controller Gerardo Capiel, gcapiel <at> References [1] [2] Gerardo Capiel VP of Engineering benetech

Uri-review mailing list
Uri-review <at>
Ira McDonald | 19 Sep 18:45 2013

Request for Apps Area review of IPP over HTTPs and 'ipps' URI Scheme (19 September 2013)


The IEEE-ISTO PWG Internet Printing Protocol WG would like to request
IETF Apps Area review of our IPP over HTTPS Transport Binding and
'ipps' URI Scheme:

Please note that this document has been already been reviewed on the
IETF URI Review mailing list (and revised accordingly).

This document does NOT specify a new protocol, but merely a transport
binding for IETF IPP/1.1 (RFC 2910/1911) that requires that TLS always
be started *before* sending any HTTP application layer requests - as
opposed to using the rarely implemented HTTP Upgrade (RFC 2817),
a source of security problems in shipping IPP printers (essentially all
network printers for the last decade).

- Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document)

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
mailto:blueroofmusic <at>
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

apps-discuss mailing list
apps-discuss <at>
Jan Pechanec | 14 Aug 02:50 2013

percent encoding of '/' in one-segment non-hierarchical path component

	hi experts,

	I've recently asked here for your opinion on the PKCS#11 URI 
draft.  With your review help which I very much appreciated, the scheme 
was recently approved as a provisional scheme and I'm getting ready to 
put it on RFC tracker.

	however, there is one thing I'm not sure about and I'd like to 
ask for your opinion.  The following is an example of a pkcs11 URI:


	now, I have the following paragraph in my draft:

   More specifically, '/' delimiter of generic URI components was
   removed from available characters that do not have to be percent-
   encoded so that the initial part of a PKCS#11 URI is never confused
   with "path-rootless" part of the "hier-part" generic URI component as
   defined in Section 3 of [RFC3986].

	which is not entirely precise (I should also include 
"path-noscheme", too) and should be rephrased.  Basically what I want to 
say is that the scheme requires encoding of '/' so that generic URI 
parsers do not split the path into segments and parse the URI above as:

	scheme name:	pkcs11
	path-segment-1:	object=my-key;object-type=private;pin-source=
	path-segment-2:	etc
	path-segment-3:	pin

	I could easily fix the draft but I'm still wondering whether:

	(1) '/' is really needed to be removed from a charset that does 
NOT have to be percent-encoded

	(2) to allow non-encoded '/' and mention that if '/' are not 
percent encoded the generic URI parser may split the intended 
non-hierarchical one-segment path (ie. set of attributes) into multiple 

	(3) to allow non-encoded '/' and does not discuss the generic 
parser issues

	it's easy to guess that people will use unencoded slashes in the 
pin-source attribute no matter what I do and that PKCS#11 URI parsers 
will have to accept it.  Choosing (1) then seems a bit useless to me.  
I'm leaning to (2) but I'm not sure it's permissible to do that.

	I'm reading rfc3986 again.  "2.2. Reserved Characters" suggests 
that since '/' is not a delimiter in the PKCS#11 URI, it does not have 
to be percent encoded.  Also, the next paragraph also under 2.2 makes me 
think that (2) might be really a good solution since '/' can be part of 
the pin-source attribute data:

   URI producing applications should percent-encode data octets that
   correspond to characters in the reserved set unless these characters
   are specifically allowed by the URI scheme to represent data in that

	however, I'm really not sure and still thinking about generic 
parsers splitting the path into multiple segments.  I'm hoping you could 
help me with some insight.

	best regards, Jan.


Jan Pechanec <jan.pechanec <at>>