Marco Pontello | 10 Jan 15:16 2016
Picon
Gravatar

URI scheme registration request: blockchain

Hello!

This is a request for a new URI scheme.
Thanks for the attention.


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

Scheme syntax:
   blockchain:[//chain]</type/hash>

Scheme semantics:
   Referencing objects on a specific blockchain.

Encoding considerations:
   7-bit ASCII is sufficient.

Applications/protocols that use this scheme name:
   Crypto wallets, block explorers, etc.

Interoperability considerations:
   None.

Security considerations:
   None known or expected.

Contact:
   Registering party: Marco Pontello <marcopon <at> gmail.com>
   Scheme creator: Marco Pontello <marcopon <at> gmail.com>

Author/Change controller:
   See previous answer.

References:
   BIP 122 (Bitcoin Improvement Proposal) provide rationale & info:

   Simple test handler / demo (sort of a blockchain explorer proxy):
_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
John Wason | 13 Nov 01:42 2015

URI scheme registration request

Scheme Name:

The requested scheme improvement is for use with Robot Raconteur, a communication framework for robotics and automation. It will have the basic form "rr://" for unsecured transport and "rrs://" for transports secured using StartTLS channel upgrade.  Because Robot Raconteur is capable of running over multiple transports, the scheme will also need to specify which transport to use.  This will be accomplished using the "rr" "plus" transport type.  Currently in use transport schemes are:

rr://foo - Cloud Transport (always secure)
rr+cloud://foo - Cloud Transport (always secure)
rr+tcp://foo - TCP Transport
rrs+tcp://foo - TCP secure transport
rr+usb://localhost - USB transport
rr+pci://localhost - PCI/PCIe transport

Possible schemes for future use with websockets (currently not used)
rr+ws://foo
rrs+ws://foo
rr+wss://foo
rrs+wss://foo

Status:
Provisional

Application/protocols that use this scheme name:
None

Contact:
John Wason
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
+1-518-279-6234
wason <at> wasontech.com

Change controller:
John Wason
Wason Technology, LLC
PO Box 669
Tuxedo, NY 10987
+1-518-279-6234
wason <at> wasontech.com

Reference:
Robot Raconteur is currently a proprietary software project.  All documentation can be found at http://robotraconteur.com/documentation .  It currently has port 48653 officially registered for TCP and UDP use along with the host names "robotraconteur" and "rr-discovery".  Standardization is of interest however the exact method and commercial implications are still being investigated.

Scheme Syntax:
See "Scheme Name"

Scheme semantics:
Each scheme will point to a host (and possibly port).  The host will be "localhost" for the hardware based protocols.

Definition of Operations:
Asynchronous message stream using binary protocol.

Context of Use:
Robot Raconteur communication protocol over port 48653 (where applicable).

Internationalization and Character Encoding:
All strings in the message stream are encoded as UTF-8 and do not have any security implications.  The only part of the URI expecting to contain international characters are hostnames registered through DNS.

Security considerations:
Robot Raconteur is mainly used for communication over the local network except for the cloud transport.  All transports over the internet use TLS or DTLS security using certificates matched to each node through a UUID unless the user specifically uses unsecured TCP.  Nodes can be secured using password and certificate based authentication. The transport itself is immune to parsing attacks as it uses length prefixes for all data fields.

-- John Wason, Ph.D. Wason Technology, LLC PO Box 669 Tuxedo, NY 10987 (518) 279-6234 wason <at> wasontech.com
_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
uri-review@ditp.org | 21 Oct 11:56 2015

Review request for scheme DIS

Hello,

This a review request for a provisional registration of the URI scheme 
name DIS. You will find the draft registration form below.

DIS is the acronym of Distributed Information System. This system is in 
design process and only partially implemented. It will use the protocol 
DITP (Distributed Information Transfer Protocol). As recommended I 
should use dis as scheme name instead of the protocol name ditp. Is that 
right ?

I don't find the "Security consideration" very informative. What is it 
suppose to apply to ? The URI interpretation, the protocol, ...?

-------------------------

Scheme name: dis

Status: Provisional

Scheme syntax: dis:<path>
     A DIS URI has no authority, query or fragment part.
     The path segments uses exclusively the characters
     '-', '_', '~, '.', '0' to '9', 'A' to 'Z' and 'a' to 'z'.
     The path may be absolute or root less.
     The total length of a dis URI, including the scheme
     name, is limited to 66 characters.
     URI examples: "dis:", "dis:/", "dis:~", "dis:/-OvsR8/345"

Encoding considerations:
     Not all combinations of the valid chars form a valid
     URI.

Applications/protocols that use this scheme name:
    The URI is a reference to an information stored in the
    Distributed Information System (DIS). The URI is
    intended to be used with Web applications.

Security consideration:
    Unknown, use with care.

Contact: Christophe Meessen <uri-review [at] ditp.org>

Change controller: same as contact

References: http://www.ditp.org

--

-- 
Ch.Meessen
David_Warden | 28 Sep 02:30 2015
Picon

Updated VNC Scheme draft available

Hi all,

An updated version of the proposed VNC URI scheme is now available:
http://www.ietf.org/id/draft-warden-appsawg-vnc-scheme-05.txt

This draft clarifies in Section 3.2 that applications detecting security sensitive parameters in the URI
should not persist that data unless it is encrypted. Users should avoid including sensitive parameters
in environments where they may be accessed and stored by generic URI-handling applications.

The table of contents section titles have also been updated to reflect previous changes. 

David Warden
Software Development Principal Engineer
Dell | Enterprise Solutions Group 
Sean Leonard | 26 Sep 00:58 2015

Request -02 review of SHA URIs

Hello URI Reviewers:

I request review of the SHA URIs in this draft-02, per RFC 7595. The URI schemes are "sha1", "sha256",
"sha1msg", and "sha256msg", respectively.

Most feedback was incorporated, or at least considered, in this document. If folks feel that their
feedback is not reflected please contact me and I will look into it further.

Thank you,

Sean

Begin forwarded message:

> From: internet-drafts <at> ietf.org
> Subject: New Version Notification for draft-seantek-sha-uris-02.txt
> Date: September 25, 2015 at 3:51:02 PM PDT
> 

A new version of I-D, draft-seantek-sha-uris-02.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-sha-uris
Revision:	02
Title:		URI Schemes for SHA-1 and SHA-256
Document date:	2015-09-25
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/internet-drafts/draft-seantek-sha-uris-02.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-sha-uris/
Htmlized:       https://tools.ietf.org/html/draft-seantek-sha-uris-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-seantek-sha-uris-02

Abstract:
  This document registers Uniform Resource Identifier schemes for use
  with certain Secure Hash Algorithm (SHA) functions, namely SHA-1 and
  SHA-256. The purpose is to identify data streams and content in a
  simple, "drop-in" way within the URI infrastructure.

Attachment (smime.p7s): application/pkcs7-signature, 4831 bytes
_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
David_Warden | 22 Sep 19:28 2015
Picon

URI Review of VNC Scheme

Hi everyone,

I've submitted a VNC scheme document:
http://www.ietf.org/id/draft-warden-appsawg-vnc-scheme-04.txt 

Hopefully this will allow VNC clients to be launched from other applications while avoiding conflicts
among competing schemes. 

Review and comments from members of this list are welcome. 

This document has been reviewed to some extent in the applications area working group (apps-discuss) and
by publishers of VNC clients. Upon advice of the area director, we plan to publish this as an independent
submission. As part of this process, I have been advised to request additional review on this list. 

Thanks,

David Warden
Software Development Principal Engineer
Dell | Enterprise Solutions Group 
Adrian Hope-Bailie | 17 Sep 10:14 2015

Scheme with both hierarchical and non-hierarchical elements

Hi list,

My company is in the process of designing a URI scheme to address resources that are part of a complex distributed system.

Some of the resources make sense to be addressed via a hierarchical syntax as they have sub-resources and related resources which could be addressed relative to the parent.

eg: scheme://root-resource/sub-resource/other-relative-resource

However, there are other resources which do not fit this pattern. They stand alone and I am considering using a different syntax for these.

eg: scheme:namespace:resource-identifier

Is it considered bad practice to have a URI scheme that mixes these two forms?

Thanks for the help,
Adrian
_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
Jennifer Clark | 16 Sep 15:21 2015

IANA Customer Feedback

Dear IANA Customer,

ICANN strives to continuously improve its delivery of the IANA functions. Please take just 5 minutes to participate in the 2015 IANA Customer Survey. Your feedback is essential to help us improve our service to you.

This short survey is being managed by Ebiquity, an independent research firm. Ebiquity is committed to protecting the confidentiality of all respondents, in line with the Code of Conduct of ESOMAR and CASRO. This means data is reported to ICANN in aggregate, so that all opinions are confidential and not attributed to any specific individual.

Please complete the survey hosted at https://www.ebiquityinsights.com/E0181/index.pl?surveynumber=71823 which will remain open until October 13, 2015. ICANN will summarize the results and publish the summary in December 2015.

We appreciate your time and helping us improve the delivery of the IANA functions.

If you have any questions, please contact me at jennifer.clark <at> ebiquityinsights.com or Marilia Hirano at marilia.hirano <at> icann.org.

Yours sincerely,

Jennifer Clark
Account Director, Ebiquity

If you would not like to receive further emails about this research project please reply to this message and type REMOVE in the subject line.

_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
Marilia Hirano | 10 Sep 18:56 2015

IANA 2015 customer survey

Dear IANA Customer,

ICANN strives to continuously improve its delivery of the IANA functions.
We have engaged Ebiquity, an independent research firm to run our 2015 
customer survey and jennifer.clark <at> ebiquityinsights.com will send you an
invitation to participate early next week.

Ebiquity is committed to protecting the confidentiality of all respondents
in line with the Code of Conduct of ESOMAR and CASRO. This means data is
reported to ICANN in aggregate, so that all opinions are confidential and
not attributed to any specific individual.

We appreciate your time and helping us improve the delivery of the IANA
functions.
	 
If you have any questions, please contact me at marilia.hirano <at> icann.org.
	  
Yours faithfully,
	   
Marilia Hirano
Sean Leonard | 10 Sep 00:24 2015

Request Review of SHA-1 and SHA-256 URIs

Hello URI Review:

I request review of SHA-1 and SHA-256 URIs, per RFC 7595. The URI schemes are "sha1" and "sha256", respectively.

Relevant notifications and templates are below.

Thank you,

Sean

***

4.1.  Assignment of sha1 URI Scheme

      URI scheme name: sha1

      Status: Permanent

      Applications/protocols that use this URI scheme name:
        General applicability. Some examples include security
        applications and systems, database and forensic lookup
        tools, and distributed peer-to-peer protocols.

      Contact: Sean Leonard <dev+ietf <at> seantek.com>

      Change controller: IETF

      References: This document.

4.2.  Assignment of sha256 URI Scheme

      URI scheme name: sha256

      Status: Permanent

      Applications/protocols that use this URI scheme name:
        General applicability. Some examples include security
        applications and systems, database and forensic lookup
        tools, and distributed peer-to-peer protocols.

      Contact: Sean Leonard <dev+ietf <at> seantek.com>

      Change controller: IETF

      References: This document.

***

Name:		draft-seantek-sha-uris
Revision:	01
Title:		URI Schemes for SHA-1 and SHA-256
Document date:	2015-09-09
Group:		Individual Submission
Pages:		8
URL:            https://www.ietf.org/internet-drafts/draft-seantek-sha-uris-01.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-sha-uris/
Htmlized:       https://tools.ietf.org/html/draft-seantek-sha-uris-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-seantek-sha-uris-01

Abstract:
  This document registers Uniform Resource Indicator schemes for use
  with certain Secure Hash Algorithm (SHA) functions, namely SHA-1 and
  SHA-256. The purpose is to identify data streams in a simple, "drop-
  in" way within the URI infrastructure.
Attachment (smime.p7s): application/pkcs7-signature, 4831 bytes
_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
Chris Rebert | 15 Jul 10:19 2015

Review request for "redis" URI scheme

Hello again,

Per the advice of RFC 7595, I hereby present the following proposed
registration of the "redis" provisional URI scheme for review. Any
feedback is greatly appreciated. Thanks.
(Apologies if FastMail attempts to line-wrap some of the reference
URLs...)

Cheers,
Chris

********

Scheme name:  redis

Status:  Provisional

Applications/protocols that use this scheme name:
  This scheme is used by some Redis database client libraries to
  designate the Redis database to connect to, and in some cases to set
  additional connection parameters of the client library.  Redis client
  libraries implement the RESP (REdis Serialization Protocol) defined
  in "Redis Protocol specification".  This URI scheme is not part of
  that specification.

Contact:
  Registering party:
    Chris Rebert <iana.url.schemes.redis <at> chrisrebert.com>

Change controller:
  Either the registering party, or
  Salvatore Sanfilippo <http://invece.org/>

References:
  Redis, "Redis Protocol specification", 2015,
      <http://redis.io/topics/protocol>.
  Redis, "SELECT index", 2015, <http://redis.io/commands/select>.
  Redis, "AUTH password", 2015, <http://redis.io/commands/auth>.
  Zygmuntowicz, E. and Contributors, "Getting started", 2015, redis-rb,
      <https://github.com/redis/redis-rb#getting-started>.
  McCurdy, A. and Contributors, "redis.connection.ConnectionPool
      .from_url(url, db=None, **kwargs)", redis-py, August 2014,
      <https://github.com/andymccurdy/redis-py/blob/2.10.3/redis/connection.py#L733>.
  Solem, A. and Contributors, "Using Redis - Celery 3.0.25
      documentation", April 2013,
      <http://celery.readthedocs.org/en/3.0/getting-started/brokers/redis.html>.
  Driessen, V. and Contributors, "Workers: Using a config file - RQ:
      Simple job queues for Python", 2015,
      <http://python-rq.org/docs/workers/>.
  Service Stack LLC and Contributors, "Redis Connection Strings", 2015,
      ServiceStack.Redis,
      <https://github.com/ServiceStack/ServiceStack.Redis#redis-connection-strings>.
  Dollar, D. and Contributors, "redis-url: URL format", 2015,
      <https://www.npmjs.com/package/redis-url#url-format>.

Scheme syntax:
  Example: redis://:secret <at> localhost:6379/0?foo=bar

  This scheme uses a profile of the RFC 3986 generic URI syntax.
  All URI fields after the scheme are optional.
  The "userinfo" field uses the traditional "user:password" format.

  Expressed using RFC 5234 ABNF, the "path" grammar production from
  RFC 3986 is overridden as follows:
    path         = [ path-slashed ]
                 ; path is optional
    path-slashed = "/" [ db-number ]
                 ; exactly zero or one path segments
    db-number    = "0" / nz-num
                 ; nonnegative decimal integer with no leading zeros
    nz-num       = NZDIGIT *DIGIT
                 ; positive decimal integer with no leading zeros
    NZDIGIT      = %x31-39
                 ; the digits 1-9

Scheme semantics:
  URIs using this scheme are dereferenced by connecting to the
  designated Redis server via RESP and then issuing corresponding AUTH
  and/or SELECT commands if a password and/or database number
  (respectively) were specified.

  If absent, the default value of the "host" URI field is:
    "localhost" (or equivalent)
  If absent, the default value of the "port" URI field is:
    6379
    (see the corresponding entry in the Service Name and Transport
    Protocol Port Number Registry)
  The database number to use for the Redis SELECT command comes from
  either the "db-number" portion of the URI (described in the previous
  section) or the value from the key-value pair from the "query" URI
  field with the key "db".  If neither of these are present, the
  default database number is 0.
  The password to use for the Redis AUTH command comes from either the
  password portion of the "userinfo" URI field or the value from the
  key-value pair from the "query" URI field with the key "password".
  If neither of these are present, the client ought not to issue an
  initial AUTH command.
  The semantics of other "query" URI field key-value pairs are
  implementation-defined.

Encoding considerations:
  Unknown, use with care.

Interoperability considerations:
  The "fragment" URI field has no known meaning or usage.  Unless it
  becomes meaningful in the future, omitting it is strongly advised.
  Likewise, the username portion of the "userinfo" URI field has no
  clear meaning since Redis' optional password-based authentication
  does not employ a username.  Unless Redis' authentication mechanism
  changes in the future, using only the password portion of the
  "userinfo" URI field is strongly advised.
  The "query" URI field is used to specify client-library-
  implementation-specific connection parameters and is therefore not
  portable.  Using it without knowledge of which specific client
  library is going to be used ought to be avoided.
  The meaning of "path" URI field values that do not conform to the
  "db-number" grammar have no known meaning or usage.  Using such
  values ought to be avoided.
  If both a "db-number" value and a "query" URI field key-value pair
  with the key "db" are present, the semantics for what Redis database
  number to use are not well-defined.  Such situations therefore ought
  to be avoided.
  If both the username portion of the "userinfo" URI field and a
  "query" URI field key-value pair with the key "password" are present,
  the semantics for what password to use for authentication are not
  well-defined.  Such situations therefore ought to be avoided.

Security considerations:
  Not fully known, use with care.
  As these URIs might contain authentication credentials or designate
  Redis servers which allow unauthenticated access, care ought to be
  taken to not leak the credentials to unauthorized persons, e.g. by
  outputting the URIs in logs or error messages.

Gmane