Constantine Kousoulis | 22 Aug 00:53 2014

Register 'vmrc' URI scheme

Hello,

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> vmware.com

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: http://www.vmware.com/go/download-vmrc


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
here:
http://member.openmobilealliance.org/ftp/Public_documents/ARCH/REST-NetAPI/2014/OMA-ARC-REST-NetAPI-2014-0053R01-CR_ACR_IANA_Registration_addressing_review_comments.zip 

Kind regards,
Uwe 

> -----Original Message-----
> From: ext Graham Klyne [mailto:gk <at> ninebynine.org]
> 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
Picon

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
      communication.

(Continue reading)

Ben Beltran | 7 Jul 18:18 2014
Picon

Request for Provisional URI Scheme recordit

Hello,

I would like to submit a request for a provisional URI scheme. The request is located here: https://gist.githubusercontent.com/benbeltran/5fb9f0396037d7f7fc50/raw/68cc526d5eff9d4fd0208493fa90b57db42fb8a8/gistfile1.txt

Thank you

-- 
Ben Beltran

_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
Ben Beltran | 27 Jun 18:10 2014
Picon

Re: Confirm: uri-review <at> ietfa.amsl.com:U6l4YA7NdPYR:9uRl5qsERCviWf4FW_C74crqeALLhNMC31at5A

another, huh...

-- 
Ben Beltran

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


Confirmation of list posting -- confirmation ID: U6l4YA7NdPYR

The ietf.org mailing-list server has received a list posting from
'Re: Confirm:
=?utf-8?Q?uri-review=40ietfa.amsl.com=3AU6l3-wxxJogz=3ART5V4YFlvlG7H0c8NZpSkclbsMRvQfOOKtIEKg?='

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> ietfa.amsl.com,
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> ietf.org.

_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
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> pocock.pro Author/Change controller Daniel Pocock, daniel <at> pocock.pro References 1. http://life.itu.int/radioclub/rr/res-13.pdf
_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
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://mathmlcloud.org/m/uniqueexpressionid 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> alum.mit.edu Author/Change controller Gerardo Capiel, gcapiel <at> alum.mit.edu References [1] http://www.w3.org/community/groups/proposed/#mathprotocol [2] https://wiki.benetech.org/display/MATH/Protocol+Handlers+for+External+Applications+to+Process+MathML Gerardo Capiel VP of Engineering benetech

_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
Ira McDonald | 19 Sep 18:45 2013
Picon

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

Hello,

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:

http://www.ietf.org/internet-drafts/draft-mcdonald-ipps-uri-scheme-08.txt

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).

Cheers,
- 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 - IEEE-ISTO PWG IPP WG
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
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic <at> gmail.com
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> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
Jan Pechanec | 14 Aug 02:50 2013
Picon

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:

	pkcs11:object=my-key;object-type=private;pin-source=%2Fetc%2Fpin

	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 
segments

	(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
   component. 
   ...

	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> oracle.com>
Mirko Nosenzo | 13 Aug 14:20 2013
Picon

Re: Review Request of new URI Scheme

Hi Ted,
feedready:// uses http but by using feedready:<absolute_uri> the user can specify a different protocol.
Actually the app supports http and https only.

Since the resource is simply downloaded, the fragment is ignored.

Thanks,
Mirko

/*******************************************************************/
/*  Mirko Nosenzo   /   Software Architect   /   Incomedia   */
/*  mirko.n <at> incomedia.eu   /   http://incomedia.eu            */
/*******************************************************************/

Il giorno 12/ago/2013, alle ore 19:31, Ted Hardie <ted.ietf <at> gmail.com> ha scritto:

Howdy,

The core of the registration seems to be this

Scheme syntax:
   feedready:<absolute_uri> or feedready://<hierarchical part>
   examples: feedready://example.com/rss.xml and feedready:https://example.com/rss.xml

feedready as a scheme with a 3986 hierarchical part seems to be pretty easy to parse. I'm a little concerned, though, about the other form, which apparently takes an unescaped URI as an argument but is presented as if it were a hier-part.  Does this get used with anything other than http and https?  You're also sure that this can never be used with a fragment?

regards,

Ted

_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
Mirko Nosenzo | 9 Aug 12:25 2013
Picon

Review Request of new URI Scheme

Hello,
please review the following URI scheme:

-------------------------------------------------------------------
Resource Identifier (RI) Scheme name: feedready 

Status: provisional

Scheme syntax:
   feedready:<absolute_uri> or feedready://<hierarchical part>
   examples: feedready://example.com/rss.xml and feedready:https://example.com/rss.xml

Scheme semantics:
   FeedReady is a feed reader application developed by Incomedia.

Encoding considerations:
   Unknown, use with care.

Applications/protocols that use this scheme name:
   FeedReady application

Interoperability considerations:
   Unknown, use with care.
   May be unsuitable for open use on the public internet.

Security considerations:
   Unknown, use with care.

Contact:
   Registering party: Mirko Nosenzo <mirko.n <at> incomedia.eu>
   Scheme creator: Incomedia

Author/Change controller:
   Either the registering party or someone who is verified to represent
   the scheme creator.  See previous answer.

References:
   http://feedready.com
-------------------------------------------------------------------

Thanks,
/*******************************************************************/
/*  Mirko Nosenzo   /   Software Architect   /   Incomedia             */
/*  mirko.n <at> incomedia.eu   /   http://incomedia.eu                       */
/*******************************************************************/

Gmane