Re: [Uri-review] Is TCP a URI scheme?

Martin J. Dürst <duerst@it.aoyama.ac.jp> Mon, 25 February 2019 05:56 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20078130ED9 for <uri-review@ietfa.amsl.com>; Sun, 24 Feb 2019 21:56:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.922
X-Spam-Level:
X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o83a6CTnMcaY for <uri-review@ietfa.amsl.com>; Sun, 24 Feb 2019 21:56:34 -0800 (PST)
Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400097.outbound.protection.outlook.com [40.107.140.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22AED12F1AC for <uri-review@ietf.org>; Sun, 24 Feb 2019 21:56:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZR4k7z9haUB/ggm/661RV923qJnQu/P9rNZkhDFyMKs=; b=I08qtvAxnd9u7Cc12dcOmP7K2leHXNR6qMbtkgCJqtvWosxXLSZbZVVj5x2ybtP90MDXCnuzo4m8PYvTHHBqGvDJjZGg3FLKxyR8ddeiW0VrlzCZs9JFEbl6XlaSmpzX/1Rr0sgoUg+yk5f+PbB1/oyn0keU9LbpxajiuijJbpA=
Received: from TYAPR01MB5149.jpnprd01.prod.outlook.com (20.179.187.18) by TYAPR01MB4893.jpnprd01.prod.outlook.com (20.179.186.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Mon, 25 Feb 2019 05:56:31 +0000
Received: from TYAPR01MB5149.jpnprd01.prod.outlook.com ([fe80::6d0f:10e4:f18d:70e7]) by TYAPR01MB5149.jpnprd01.prod.outlook.com ([fe80::6d0f:10e4:f18d:70e7%3]) with mapi id 15.20.1643.018; Mon, 25 Feb 2019 05:56:31 +0000
From: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= <duerst@it.aoyama.ac.jp>
To: Graham Klyne <gk@ninebynine.org>, Eric Johnson <eric=40tibco.com@dmarc.ietf.org>
CC: "uri-review@ietf.org" <uri-review@ietf.org>
Thread-Topic: [Uri-review] Is TCP a URI scheme?
Thread-Index: AQHUykiPYtSVFWhFqU2G/Hb/tqU6lQ==
Date: Mon, 25 Feb 2019 05:56:31 +0000
Message-ID: <4dab7004-c198-6d9e-75be-c4ab897daa2f@it.aoyama.ac.jp>
References: <CAKaEYh+X_uj39OQNLy9O+aq1pbwYftbvyjx8TG0Y84wsw_ymoA@mail.gmail.com> <CA+9kkMDYrgL17X_rFtTrA10A-UrpRLYb4iPJM2RmJ2=b12Lx2Q@mail.gmail.com> <CANu9=NcSP+rhsCR58i1RzAnA8EoaOvTWW_Tpg5eT+_xkZ7+3mg@mail.gmail.com> <38b9b695-9ac6-444c-5977-33fcb54aad6a@it.aoyama.ac.jp> <5C6FDABF.4030001@ninebynine.org>
In-Reply-To: <5C6FDABF.4030001@ninebynine.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: TYCPR01CA0111.jpnprd01.prod.outlook.com (2603:1096:405:4::27) To TYAPR01MB5149.jpnprd01.prod.outlook.com (2603:1096:404:12e::18)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [133.2.210.64]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ba29aba2-0f18-4557-ac17-08d69ae5fd71
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7025125)(7027125)(7023125)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:TYAPR01MB4893;
x-ms-traffictypediagnostic: TYAPR01MB4893:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <TYAPR01MB4893FD4BC49BA620F8CED7A0CA7A0@TYAPR01MB4893.jpnprd01.prod.outlook.com>
x-forefront-prvs: 095972DF2F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(396003)(39840400004)(376002)(366004)(346002)(136003)(189003)(199004)(14454004)(7736002)(93886005)(305945005)(186003)(66574012)(86362001)(31696002)(71200400001)(71190400001)(66066001)(508600001)(4326008)(10126004)(2906002)(8676002)(81156014)(81166006)(229853002)(8936002)(966005)(476003)(2616005)(76176011)(256004)(97736004)(102836004)(25786009)(5660300002)(52116002)(6246003)(446003)(6506007)(386003)(6486002)(53546011)(11346002)(105586002)(6512007)(85202003)(6306002)(6116002)(3846002)(106356001)(53936002)(110136005)(26005)(316002)(786003)(85182001)(99286004)(74482002)(6436002)(68736007)(31686004)(486006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:TYAPR01MB4893; H:TYAPR01MB5149.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts)
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtUWUFQUjAxTUI0ODkzOzIzOmoraXhrUWlDNkZRTGZaMG14Yy9IYmtjajJn?= =?utf-8?B?N3F2K2VFZWcxWDI5VS9pdjdYUm9uM2phTmV0MHprODBuemRkcUZkSytTakVN?= =?utf-8?B?MVRnMkVPRFZmMUZvUk1TRHc4ekc2cGRMUGZPZ3VLYUJGd0VPR3AwUnkyTy9q?= =?utf-8?B?U0hvMTlRNEhBeTdrczVqbnptWnJ3VW9TNmY4cElHc2wzY29GRkMwbFZteXhv?= =?utf-8?B?UlNKZGdEYzZ0TzRxcm0rMll1MFg5SGE2clBvY05CUHp0QjloRXE5UVdEOUJh?= =?utf-8?B?bXdpaDB3cTh4bXF4TVJuOEJ6SVAyMkVZTGtod2xQaXFEWm9mMWM5akVtVi9i?= =?utf-8?B?ZzVBVEpKNnlzNStCdTBtTTdpVVl4TkI2bGw2UlJJYUViVFErY1F5Z0dRSGhO?= =?utf-8?B?NjlRa1RwME1KZTJka2svNlVDRGdrUGZKSXVHMGcxWitoSytoMFdTKzlnaTlL?= =?utf-8?B?aVMzY3FtRy81bXB3SUZGRXZjL2VwN2hTWitoemFieW5ZLzgxVUNVazgvZGRs?= =?utf-8?B?Y0xJeFlEcnF6Z0l0NFlOVStwVTFLZHNvcENNbXpYL1VuSkd4Si96cWhvR2xa?= =?utf-8?B?RXBkckFKVEkvdTNCbC9pWDZrQloranlCWW9sSkJ5UmF4YjRMalNkbnNNQ01U?= =?utf-8?B?M0hSSmhzQk52MFhyUUtmbitURWdsWjFmSjdvUERUeFdDNXd0S0g4clJCV2Vj?= =?utf-8?B?TDJTcU1RcHdMMDlXL3U5Y0lnQjVyVHNhYVBhRVdnYmhVT2dtMFNrNE9uakZN?= =?utf-8?B?RFFKWnhtc3RtbHFtL0tJeUt2UTJ5ZW4zMmswNE51TWxhR3J0MWlwZGFPeHdH?= =?utf-8?B?ZHRCT0JFRFR3QjZHQzlTK3h0azhQZU5PeWd3ODFlMzRnMXZ0SVIrMytqYzkz?= =?utf-8?B?eGlyNmJFZSszK1hRa1ZGNEZQR2xxbVZ1eGg1a3J3djdXRkhwQ0Fwa0phT1R2?= =?utf-8?B?QkVidGRFSzZtWS9BWVdZb0tXMkNmZ3J2MzFSTWRta2J6V0EweG5uMmlma0Ux?= =?utf-8?B?cjJoT2pYMmtlV1VaU21TWk1XT3lsRUJ0T04wbHFqWHZyN3BseUhSUEQ0R1lV?= =?utf-8?B?bjErVTJaSjZlYWhWOURSM2RaTVZBVXZJME1oS05tSEJDMUplY2dZWmp0U250?= =?utf-8?B?c0E2RDlIOEVyZ3UyR3N6eXFsbDhERTBpZHNwL1g5UWkwT0o0WGk3WHFBSEhU?= =?utf-8?B?MGRMYVJ4WHg2Q1JQMXJZZSs4aVlnTjdLUE94Wi9rdWhlRXdOZFp6aUpRY0t1?= =?utf-8?B?VGQvWGk0Q0FYc0tSbnFFbmJxbmQ5d0tTZENrKzR5WWlaT0xyTVBjc2ZxNW1s?= =?utf-8?B?Mm1VT3BuUk1XWGc4WGtPMjZGQnl6Q0pVdk1wb04yclQ5L1dVdzRkNVpWMlRX?= =?utf-8?B?TGVRYXlFVzRRa1l3allRT01CWWFzMkJUcGs5ZmhXMlhRMWFnbU9mTm11MHBF?= =?utf-8?B?RHJjZTRNRkRwNzV6RXNPTENLZUNGd3N0SzQ0alQybFJRWXM5ckIwRmhzb3NN?= =?utf-8?B?enFIdmtaUm45dmJCZ2UySnV6a1FzaXg5NWpxVUZMRlBPSnFGRkx6aVB3RnMy?= =?utf-8?B?bDl1QTRpSUZ0Vk1zL2hMeXEvY3I1OFZsejJ2bkxlQTllUk1qb0lBZlRlK2U1?= =?utf-8?B?TTl5T2YxbmtXZFprSWxWWGpWR3lVMm94QlR2OE1LcXU4YkxReW9iVHBKQm1x?= =?utf-8?B?QlZHMk5JVHdpOEhkODNBUGNDSjB6N2VZTWlIU2FhU1I4MGN6RFVMUXJnQW5q?= =?utf-8?B?em1mUVMwc282MVg4dGVhQTV6M1gvVFdjMXp0MjU4UVFXQ1NGUUl2S3BRMjgx?= =?utf-8?B?Ymxld3M1Q0Zva2Q3YU94cVdGdDQ0ZWc3N0g0SG9wRjhTMFpRTUdtbVRMY0JU?= =?utf-8?B?R0xFL2FRWFArbUsvQ0xyMHlEQ3RBNEh6alM3eUJWbTB6OVQxL25BMDFEaHRL?= =?utf-8?B?RTNyVCtOQlNTWk0zY25lOFBzQzcrVGttbUJhU3FvZGwrTGdSanJ1eTBGSG5B?= =?utf-8?B?TG5uYlBhbCtxSzNQTnlJU0gyL0hIQ3lPNTJHVHVLcUk1UjlSOWV4eTdoV1NU?= =?utf-8?Q?JWo4=3D?=
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 3N4ecYytINb9Gy59QF5Phhbchq9Z/7KuY1TmDmMiU8TmC2bBk+XbN5tBLEv0mEJkekvLTK97dNsClsjeTrONB1uUL6UuDpP6GFHflm9y/m9TK2rn55LP9VnFWkwQuiF++xwa5jdzqDEDDho6fKqE/u/vLyPd4eq3F3DjZ72LD/mgWdjE/h0HEpygOAx5pvA0lfDwV0ktmBl9XcE6HO4tz5lQdGPbNg12BOWZBzqdZqVe+B79HhA/HAkteYejexmHr1SQW97tlEZDnu0wb85RMAvzCGL7EHCxXOz3CWcnZJhMVVgM2GuckYirCncItWR62go6hrO54QCMCcipFl6nzby3rxGxmIVf4zg7iMSfvKwAggZhqW1b8tdARnwNqZp/I/HF1xJij7n0AfhTDbF3Sg5uAlRfcnQdKuKbeg29MXA=
Content-Type: text/plain; charset="utf-8"
Content-ID: <9BB9C8C0F40BA945BA65582EE620321E@jpnprd01.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: ba29aba2-0f18-4557-ac17-08d69ae5fd71
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 05:56:30.9136 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB4893
Archived-At: <https://mailarchive.ietf.org/arch/msg/uri-review/bFaUk5lifCk5rOE7GLfj6sQx24o>
Subject: Re: [Uri-review] Is TCP a URI scheme?
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uri-review/>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Feb 2019 05:56:37 -0000

Hello Graham, others,

On 2019/02/22 20:19, Graham Klyne wrote:
> I have a couple of comments prompted by this thread..
> 
> 
> 1. I propose that it is quite possible to use a string that conforms to 
> URI syntax (explicitly or otherwise) without it being a URI.  So what 
> makes it a URI?  Two touchstones that I apply are: (a) "what does it 
> identify", and (b) "does it make sense to use it in a context where 
> other URI schemes might equally be used" (e.g., as an href in an HTML 
> document, or as a link relation type on an HTTP Link: header field).

I agree. My main point was that URIs and URI schemes have been 
spreading, so href in an HTML document and link relation type in an HTTP 
Link: header field are only the top of the iceberg nowadays.

> 2. Registration of *provisional* URI schemes is now first-come, 
> first-served, without formal review, subject to satisfying some simple 
> administrative requirements (cf. [1]).
> 
>     Permanent registration is a different matter, and does involve 
> stricter requirements and formal review [2], which in turn involves some 
> judgement by the reviewer about whether the requirements are satisfied.  
> As the current reviewer, I will typically look for indications of 
> working group approval, similar from other recognized bodies like W3C, 
> or "IETF review" (formerly "IETF consensus") [3] to inform that judgement.
> 
> 
> [1] https://tools.ietf.org/html/rfc7595#section-4
> 
> [2] https://tools.ietf.org/html/rfc7595#section-3
> 
> [3] https://tools.ietf.org/html/rfc8126#section-4.8
> 
> #g
> -- 
> 
> 
> PS: since [4], I've personally come to further downplay the URI/URL 
> distinction. I regard it as more to do with context of use than 
> something inherent to the actual string form used, in that *any* 
> identifier can be a locator given the right infrastructure (e.g,. DOIs), 
> and any locator can potentially be used as an identifier.
> 
> [4] https://www.w3.org/TR/uri-clarification/

For those who haven't been involved in that effort, and who haven't 
bothered to click on the link and check the data, it's from 2001, so 
really already quite a while ago. But it still very much (or even more 
so) applies at present.

Regards,   Martin.

> 
> 
> On 22/02/2019 04:54, Martin J. Dürst wrote:
>> Hello Eric, others,
>>
>> On 2019/02/22 09:49, Eric Johnson wrote:
>>
>>> Speaking somewhat on behalf of TIBCO, I'm not sure that the use of a 
>>> string
>>> that begins "tcp:" means that what is contained is necessarily a URL. 
>>> I did
>>> a small amount of very informal questioning of some of my fellow 
>>> employees,
>>> and didn't get the impression that the use of "tcp:" was anything other
>>> than a signal for the type of thing that followed the prefix, and not
>>> strictly speaking a "resource" locator.
>>
>> This overlaps quite a bit with what I'd have written as an answer to the
>> original question if I had had some spare time when that comes up.
>>
>> One of the core points of URIs is that they unify syntax at a very high
>> level (the level of foo:). That makes them very useful for pointing at
>> various things, from various places. The original place was the href
>> attribute of the <a> element in HTML. There, the main schemes were
>> http:, https:, ftp:, mailto:, and so on.
>>
>> Other places where there was a need to point to something reused URIs,
>> but once in a while, there was a need to point to something that didn't
>> yet have an URI scheme. With the use of URIs expanding, such things got
>> more and more diverse. That somebody somewhere wanted to point to a
>> (potential) tcp connection, and would used tcp: for that, was just a
>> matter of time.
>>
>> For quite a while, registration of URI schemes was handled rather
>> strictly. It's supposed to be easier today, but it's still some work,
>> some discussion, and some wait. Also, the documents describing URIs are
>> not necessarily an easy read for everyone, because they use general
>> terms that can easily be misunderstood.
>>
>> Also, please note that we are talking about URIs here, not URLs, so it's
>> resource Resource Identifier, not Locator. And "resource" is really
>> extremely general, even if for some schemes (e.g. mailto:), some care is
>> needed when describing what exactly it stands for.
>>
>>   > On Fri, Feb 1, 2019 at 9:18 AM Ted Hardie <ted.ietf@gmail.com>; wrote:
>>   >
>>   >> I don't believe it has ever been registered, even provisionally, 
>> but you
>>   >> can find example syntax in both IBM and TIBCO documentation of their
>>   >> usage.  See, for example:
>>   >>
>>   >>
>>   >>
>> https://docs.tibco.com/pub/activespaces/2.1.6/doc/html/GUID-CAE482DF-C20D-46C4-AD2D-337535551423.html 
>>
>>
>> Looking at that page, it says "TCP Discovery URL Format". I'm not
>> familiar with this "discovery" part, but it may have been better to use
>> something like "tcp-disc:" or so as a prefix.
>>
>> Regards,   Martin.