Subject: [Uri-review] Register 'vmrc' URI scheme

From: Constantine Kousoulis <[email-masked]>
Date: Thu, 21 Aug 2014 22:53:58 +0000

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: [email-masked]

Thank you,
Constantine Kousoulis

---

From: Ted Hardie <[email-masked]>
Date: Fri, 22 Aug 2014 02:42:36 -0700

Hi Constantine,

A couple of questions:

Resource Identifier (RI) Scheme name: vmrc
Status: provisional

URI scheme syntax.

vmrc://[<user>|(<ticket-type>:<ticket>)@]<host>[:<port>][/[<path>][?<object-type>=<object-id>][&[...]]

   example: vmrc://username@vsphere-server/
   example: vmrc://clone:ticket@vsphere-server/?moid=42

In this example, the "clone:ticket" portion of the URI is considered
userinfo in 3986 terms, is that correct?  If that is the case, note this
advice from RFC 3986:

   Applications should not render as clear text any data
   after the first colon (":") character found within a userinfo
   subcomponent unless the data after the colon is the empty string
   (indicating no password).

That would result in some applications rendering this as clone:######.
Will the service be robust in the presence of this behavior?

   example: vmrc://vcloud-server/urn:vcloud:vm:42

In URI terms, urn generally refers to Uniform Resouces Names; I do not see
vcloud in the list of URN NIDS here:
http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml; is
this inteded to be a URN?  If not, it should probably not use urn in the
example, since that will lead to confusion.  If it is, then it should be
registered and the syntax there reviewed.

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

If you get a URI with a fragment identifer, is this permitted?  Is there a
specific behavior expected?

Ted

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.
   Unknown, use with care.
Security considerations.
   Unknown, use with care.
Contact.
   Registering party: Constantine Kousoulis <ckousoulis&vmware.com>
   Scheme creator: VMware
Author/Change controller.
   Either the registering party or someone who is verified to represent
   the scheme creator.  See previous answer.
References.
   https://www.vmware.com/support/developer/vc-sdk/,
https://www.vmware.com/support/pubs/vcd_pubs.html

On Thu, Aug 21, 2014 at 3:53 PM, Constantine Kousoulis <
[email-masked]> wrote:

> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
>
>

---

From: Constantine Kousoulis <[email-masked]>
Date: Fri, 22 Aug 2014 22:30:48 +0000

Thanks for the feedback, Ted.

About “clone:ticket”:

* Yes, that portion of the URI is userinfo.
** Hosts (such as VMware infrastructure servers) that users of this scheme interact with provide different mechanisms for identifying a user or user session. Some use authentication tickets – the example above would be a ticket to clone a user session on the host.

* Tickets should be treated as opaque strings, and applications shouldn’t need to present them to users.
** It is fine (and appropriate) if an application chooses to render the string by substituting a character for the ticket contents.
** If a ticket is tampered with, the host will reject it. This amounts to failed authentication, and applications should be comfortable handling that (for example, by prompting the user to enter a username/password).

* Although many of the hosts support username/password authentication, our proposed scheme for userinfo intentionally does not allow for it. URLs may be created with *either* username@ *or* foo:bar@, in which case foo:bar is interpreted as something specific to the host.
** We want to discourage users from sharing URLs with a user’s password in plaintext, and a scheme where username:password is semantically incorrect seems a sensible way to accomplish that. Let me know if you have thoughts/suggestions about this.

(Perhaps I should mention some of this information about tickets under security considerations?)

About “urn:vcloud:vm:42”:

* I agree that we should remove that example. vcloud isn’t registered – that format is unique to VMware’s vCloud product.
** Applications would interact with the host to resolve the path into an object – we can use a different path construct or just rely on query components for that.

About “fragment”:

* I left fragments out of the scheme because I couldn’t find examples where they would be necessary or useful (at least not at this time). The general purpose of this scheme is to identify some object(s) within an infrastructure, and so conceptually fragment fits.
** Example: “vmrc://host/?moid=vm-42#settings” could be interpreted as a way to request settings information about the VM identified by the rest of the scheme.
** Handlers of URLs following this scheme should ignore parts of the [path, query, fragment] they don’t support (falling back on showing the resource they can support, which for a base case would just be the host as an object itself).

I feel comfortable adding fragment into the scheme and adding a usage note that, for the scheme generally, handlers should gracefully handle any parts that either identify resource types unsupported by the application or that cannot be found. Do you have any guidance on what is appropriate for cases like this?

Good questions. Let me know if you have more.
-- Constantine

From: Ted Hardie [mailto:[email-masked]]
Sent: Friday, August 22, 2014 2:43
To: Constantine Kousoulis
Cc: [email-masked]
Subject: Re: [Uri-review] Register 'vmrc' URI scheme

Hi Constantine,
A couple of questions:

URI scheme syntax.

   example: vmrc://username@vsphere-server/
   example: vmrc://clone:ticket@vsphere-server/?moid=42
In this example, the "clone:ticket" portion of the URI is considered userinfo in 3986 terms, is that correct?  If that is the case, note this advice from RFC 3986:

   (indicating no password).
That would result in some applications rendering this as clone:######.  Will the service be robust in the presence of this behavior?

   example: vmrc://vcloud-server/urn:vcloud:vm:42
In URI terms, urn generally refers to Uniform Resouces Names; I do not see vcloud in the list of URN NIDS here:  http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml<https://urldefense.proofpoint.com/v1/url?u=http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=ISxV7LrF7I6HB1aPKfucOJeHxUjaGMfXS1dnnHjgZsY%3D%0A&m=c6nfUzh5Y%2FqWZsxNbtWwDh%2BGZEtuY18yFnl8Wk2zP%2FA%3D%0A&s=b2a40b0be100a2015450e59f65a236caa3965e6d6169643f23525a1192eb8498>; is this inteded to be a URN?  If not, it should probably not use urn in the example, since that will lead to confusion.  If it is, then it should be registered and the syntax there reviewed.

URI scheme semantics.
   Access an object (like a virtual machine) located in a virtual environment (like VMware vSphere).
If you get a URI with a fragment identifer, is this permitted?  Is there a specific behavior expected?
Ted

Encoding considerations.
   Unknown, use with care.

Interoperability considerations.
   Unknown, use with care.
Security considerations.
   Unknown, use with care.
Contact.
   Registering party: Constantine Kousoulis <ckousoulis&vmware.com<http://vmware.com>>
   Scheme creator: VMware
Author/Change controller.
   Either the registering party or someone who is verified to represent
   the scheme creator.  See previous answer.
References.
   https://www.vmware.com/support/developer/vc-sdk/, https://www.vmware.com/support/pubs/vcd_pubs.html

On Thu, Aug 21, 2014 at 3:53 PM, Constantine Kousoulis <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

For more information, please contact me: [email-masked]<mailto:[email-masked]>

Thank you,
Constantine Kousoulis

_______________________________________________
Uri-review mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/uri-review<https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/uri-review&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=ISxV7LrF7I6HB1aPKfucOJeHxUjaGMfXS1dnnHjgZsY%3D%0A&m=c6nfUzh5Y%2FqWZsxNbtWwDh%2BGZEtuY18yFnl8Wk2zP%2FA%3D%0A&s=e082caac47e221e596cc999f4a01f70d1bf2deab0455f4e95d24a34ac78e441a>