Re: [Stackevo] an agenda for Wednesday's meeting
Dave Thaler <dthaler@microsoft.com> Mon, 25 March 2019 14:20 UTC
Return-Path: <dthaler@microsoft.com>
X-Original-To: stackevo@ietfa.amsl.com
Delivered-To: stackevo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3E212049A for <stackevo@ietfa.amsl.com>; Mon, 25 Mar 2019 07:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 tOrgvhjmTwAg for <stackevo@ietfa.amsl.com>; Mon, 25 Mar 2019 07:20:24 -0700 (PDT)
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730115.outbound.protection.outlook.com [40.107.73.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE561120432 for <stackevo@iab.org>; Mon, 25 Mar 2019 07:20:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2McKSqSBM3m7jMzPv8R5w9ga9sXMozCB9k+pBD4bCb0=; b=j6ZHFfikvtkWn9/1ecoX8L0NzRmHjH87Irh6DJRunjL3+kp1X8xtZopwpoOlXMQnddwREojL5Za9pR3JsOKTeCVcjcMImJxOLAbA710J4QlY8RWHYAmcWTa9A9XGzj2+j5Miivh9+ZsdwpFrm5/Yzp6vTa52Bc4EsLStROGgrgY=
Received: from CY4PR21MB0168.namprd21.prod.outlook.com (10.173.192.150) by CY4PR21MB0118.namprd21.prod.outlook.com (10.173.189.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.2; Mon, 25 Mar 2019 14:20:21 +0000
Received: from CY4PR21MB0168.namprd21.prod.outlook.com ([fe80::e4d9:80f9:fab1:345c]) by CY4PR21MB0168.namprd21.prod.outlook.com ([fe80::e4d9:80f9:fab1:345c%10]) with mapi id 15.20.1771.002; Mon, 25 Mar 2019 14:20:21 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, Stackevo <stackevo@iab.org>
Thread-Topic: [Stackevo] an agenda for Wednesday's meeting
Thread-Index: AQHU4xOrD8qiCsXMGkSRSX6G26eH+qYcZCzg
Date: Mon, 25 Mar 2019 14:20:21 +0000
Message-ID: <CY4PR21MB0168EB6243D0C52F0320446FA35E0@CY4PR21MB0168.namprd21.prod.outlook.com>
References: <6C66F810-1168-42C3-B4B5-CBBABBE60349@trammell.ch>
In-Reply-To: <6C66F810-1168-42C3-B4B5-CBBABBE60349@trammell.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-03-25T14:20:16.9004310Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=978c0a4d-2222-4914-9410-f3e505ed5455; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
x-originating-ip: [2001:67c:370:128:e9a4:4524:8065:102]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2a96304a-f70d-4417-4542-08d6b12d03f9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(49563074)(7193020); SRVR:CY4PR21MB0118;
x-ms-traffictypediagnostic: CY4PR21MB0118:
x-ms-exchange-purlcount: 1
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com;
x-microsoft-antispam-prvs: <CY4PR21MB01185A9DA0F94C0ACD677862A35E0@CY4PR21MB0118.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4125;
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39860400002)(346002)(136003)(366004)(13464003)(199004)(189003)(256004)(14444005)(5024004)(105586002)(7736002)(25786009)(106356001)(86612001)(476003)(33656002)(68736007)(6306002)(9686003)(55016002)(6246003)(53936002)(86362001)(99936001)(74316002)(6116002)(8936002)(229853002)(2906002)(110136005)(22452003)(14454004)(46003)(316002)(102836004)(11346002)(76176011)(966005)(478600001)(446003)(6436002)(52536014)(8676002)(81156014)(81166006)(10090500001)(97736004)(6506007)(10290500003)(71190400001)(71200400001)(53546011)(66574012)(5660300002)(305945005)(8990500004)(186003)(486006)(7696005)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0118; H:CY4PR21MB0168.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: nPcmoVzQmZakqyBekpTzHZoK/IP5DZxEa+luxY9YA3vcHAymwHI1XLR4fJHXWGTU1/7iwD3rbjS1tR0krKv7kPKqxFEGwxTUnREknq/sC2g8hFgO3cMax/WdyisumNrB+3ek+14MGrgH38l+48ZBogpLaWW83DlbRYh8w5er+27UzIr+rl8+WUvwmyjuycdS2LArYTYvbIM+MNDXKYOEzxMZEyHFrVYAQTX2lGEyMlCdhp9yBdZgZVet3l5CYJnnEp88rUU39EgwRTPNMGLyzBllOiACEl78nGM/KVcht7fLkh4q96xGrv+bZteTt3YksedF9I0XCz2K7Fa+5qaGb6+mib02pCVi/KQZwZgdvpx2wGT623KJmNBca8oxNv+flls5c52tcfFLYjxlfxT//h93aGQfgHhJK0VhMCG9/TM=
Content-Type: multipart/mixed; boundary="_002_CY4PR21MB0168EB6243D0C52F0320446FA35E0CY4PR21MB0168namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a96304a-f70d-4417-4542-08d6b12d03f9
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 14:20:21.6585 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0118
Archived-At: <https://mailarchive.ietf.org/arch/msg/stackevo/i3gV3x6BIpfRXR8UsOIQNcu8wsY>
Subject: Re: [Stackevo] an agenda for Wednesday's meeting
X-BeenThere: stackevo@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IP Stack Evolution Program Mailing List <stackevo.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo>, <mailto:stackevo-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo/>
List-Post: <mailto:stackevo@iab.org>
List-Help: <mailto:stackevo-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo>, <mailto:stackevo-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2019 14:20:30 -0000
There's also the recently expired draft draft-thaler-appsawg-multi-transport-uris-02 that Martin previously reviewed and provided a bunch of feedback on in attached, where among other things he said: "At some point, this work probably needs to feed into a URI-bis that better serves non-HTTP uses. In writing this up, I started to think that RFC 3986 isn't really a great baseline. (In case it's not obvious, this is not me volunteering to lead that effort, though I would happily contribute some effort.)" I haven't done anything with the draft since then, though I think at that time Martin was considering whether he had time to become a co-author to reorganize the draft to address his feedback. It's fine with me if someone else wants to help or take over as lead editor. I still think this is something that should be done, whether it's part of the IAB program or not. Dave -----Original Message----- From: Stackevo <stackevo-bounces@iab.org> On Behalf Of Brian Trammell (IETF) Sent: Monday, March 25, 2019 3:04 PM To: Stackevo <stackevo@iab.org> Subject: [Stackevo] an agenda for Wednesday's meeting Greetings, all, >From discussions with the IAB and in the hallway in Prague, I'd propose a few topics of discussion for our meeting on Wednesday (13:20 in Herkovcka, mezzanine level) (1) next/final steps on draft-thomson-use-it-or-lose-it: we'd like to get this draft ready to send up to the IAB for adoption soon. (2) next/(final) steps for the Stack Evolution Program: what else do we want to do after finishing use-it-or-lose-it? This is my now-traditional annual attempt to declare victory and close the program. (3) Following up on a question Aaron posed in the hallway: "To what extent is compute a part of the current Internet architecture, and to what extent are we poorly served by not treating it as such?". This is possibly a less intractable rephrasing of the "what is an endpoint?" question. The end-to-end model we use for the Internet really only applies up to a front-end load balancer for an increasing proportion of Internet traffic. To borrow a phrase from the past, everything on the other side of that LB is a catanet, albeit one that still kinda-mostly runs some transport/application stack atop IP. What implications does this development (which has basically already happened with the migration of everything on the server-side not already on a CDN into one or more public clouds) have for the evolution of the stack and the architecture? We could probably spend unbounded time on the question above; I'd like to know if anyone has other questions to address? Thanks, cheers, Brian _______________________________________________ Stackevo mailing list Stackevo@iab.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iab.org%2Fmailman%2Flistinfo%2Fstackevo&data=02%7C01%7Cdthaler%40microsoft.com%7C7f5785fbb227449e01fd08d6b12accc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636891194711209717&sdata=1%2BR09g5mqgipFRxwNR2Fsyfmao0HOM%2F4JoUhlgT7cpI%3D&reserved=0
--- Begin Message ---This is a really hard problem to talk about. I think that this draft takes a few important steps, but I found that it struggled a little with focus and clarity at a few points. I also struggled to produce this review, so I apologize for how rough it is. The primary concern I have is that it doesn't really recognize the full extent of the role that URLs can take in the processes they support. Concentrating more on that aspect might help us more clearly distinguish between use cases for different URI schemes and provide more concrete advice about how to design URLs that work for those use cases. Right now, URL design seems to be completely adhoc and arbitrary. I think that the CoAP schemes are a great example of a case where a scheme is minted without understanding the usage context properly. Using the schemes we know as a model is easy, but I think that this pattern of cargo-culting has made the problem worse and not better. For instance, HTTP is not a great role-model, though it has probably reached something of a comfortable equilibrium. At some point, this work probably needs to feed into a URI-bis that better serves non-HTTP uses. In writing this up, I started to think that RFC 3986 isn't really a great baseline. (In case it's not obvious, this is not me volunteering to lead that effort, though I would happily contribute some effort.) # Some Easy Points I wonder if this should talk about URLs rather than URIs. That is, the use of identifiers that are not also locators aren't really in scope. The use of URIs as a general purpose identifier is probably too broad for a context where you are taking a string as input to a protocol. The use of "transports" here is easy to grasp, but it risks missing some of the critical usage models. This really needs to concern itself with the entirety of the resolution mechanism, whatever that is. I would use the word "protocol" rather than "transport", because these usages refer to an entire stack, which might - as I point out below - encompass discovery mechanisms in addition to simply switching at one layer of the stack. For instance, it is possible to use HTTP to access a CoAP URL, even if that might not work in all the ways that you might expect. In fact, some still hold hopes for HTTP being usable for URIs of all schemes (just try sending a mailto: URI to a web server and see how far that gets you...). ((At some point we should probably start to discuss the notion of a limited vocabulary with respect to what you can *do* with a URL. That is, a lot of protocols assume that an undecorated reference means "GET" when no other context is provided. Is there some cross-scheme interpretation of URL "resolution", or is that best left to the context in which a URL appears? Of course, that doesn't belong here because it would explode the scope. I note here that SIP (RFC 3261) defines a "method" parameter, which suggests that sometimes this intent is not inherited from context.)) # The Meat I wonder if the focus here shouldn't be on the URL as a protocol element. What information can be bound into context (i.e., the scheme), what needs to be explicit, and what can be recovered using other mechanisms once the protocol interactions are bootstrapped. After all, a URL serves primarily as a bootstrapping mechanism. Structurally that means thinking of a URL as a container of protocol information. The scheme establishes a context, which then defines the structure. Most URLs also include an authority using a common syntax, though that part is convention as much as it is standardized. The remainder of the URL is information that is interpreted in some scheme-specific fashion. Some of that other information is designed to be passed to the authority, other information is designed for consumption by the user, and that doesn't have to be exclusive. The realization we had with HTTP was that the combination of scheme and authority was the most important part to preserve (that is, the notion of an origin as scheme+host+port as defined in RFC 6454). You can use any number of protocols to talk to a server, but the scheme identifies a specific set of semantics and the authority establishes the identity of the entity that can answer to those semantics. The discussion about the 's' in 'https://' and other such things is buried in Section 3.3, but I think that it's foundational. The idea of baking expectations regarding authentication into identifiers was an ugly necessity in HTTPS, but it had the regrettable effect of forking the identifier space at the root. Most in the community simultaneously hate this split and recognize how it was necessary. We're nudging ever closer to repairing this by gradually turning 'http://' into a ghetto, but it has been extraordinarily difficult. As an aside, it seems like this is one reason the choices in CoAP generate negative reactions. The level of similarity makes it seem like a giant mistake to mint coap and coaps (I still think that the former is an error). To then double down with so many others, when it took so much hard effort to get HTTP as far as it has, seems crazy coming from that frame of reference. However, a coap:// URL serves a very different purpose to an HTTP URL, so while maybe this is unaesthetic, it's not an inherently bad choice. HTTP is moving toward a more abstract conceptualization of the role of the URL. A single URL is a common identifier, but it does not directly identify protocols, except to the extent that discovery of alternative protocols is necessarily opportunistic. (More on this later.) The URL remains a critical protocol element, but its binding to a particular protocol stack is far more loose. And while that might be suitable for HTTP, some of that is because of its position as a mature and well-established protocol. Other protocols might have different constraints. For instance, the question about how to signal choice of transport in CoAP should have suggested a bigger question as to whether a URL format in the style of HTTP was entirely appropriate for use with CoAP. If we accept the abstract notion of scheme+authority as being a goal, then it makes it seem like the CoAP choices were poor. However, if you instead admit the possibility that a URL might be used for different purposes, then there are different questions to ask. For CoAP, the notion of scheme+authority is one that might suggest a similar design to HTTP, but that cargo-culting ignored the true needs of the protocol, where avoiding uncertainty about protocol is important. Servers in CoAP can't really afford to support multiple protocols. The uses that rely on URLs really benefit from a discovery process, which implies additional complexity and latency for common operations. Even an opportunistic discovery like with HTTP might not be feasible, because that design implies support for multiple protocols. That suggests a different taxonomy to the one you describe: 1. Implicit discovery - in this, the URL has a default protocol, but alternative protocols might be discovered. This allows a URI scheme that defines just one option to develop new means of reaching the same resource, implying that fixed identification isn't necessarily a terminal condition. Implicit discovery admits the possibility of inline upgrades (HTTP Upgrade), opportunistic upgrade techniques like Alternative Services (RFC 7838). The worst drawback of this scheme is that it implies indefinite support of the default protocol in order to either support this discovery process and provide continuity in cases where discovery fails. You also can't change expectations about semantics (the http/https problem). 2. Explicit discovery - a URL is a more abstract concept that requires the use of a discovery step. Of course, this isn't fundamentally any different to having a single protocol if you consider the discovery process to be part of that protocol. The drawback of having this sort of indirection is that it naturally delays the resolution process. 3. Definitive protocol identification - the URL contains an explicit protocol identifier. This is likelybetter suited to uses where the role of a URL is entirely functional. This could be the right choice for purely function URLs, where the lack of ambiguity is a feature. For instance, if the URL is used to configure a database server (postgresql://) or contact a CoAP endpoint (coaps://). This leaves the question of how to identify the protocol in the URL. We currently have a real mess of options across different URI schemes and protocols. You could even imagine providing a menu of options in the same URI with the user of that URI being able to choose. That is less inflexible, but more user-hostile. (Maybe this is what is implied by Section 3.2 ... ?) Not sure where happy eyeballs fits in this taxonomy. It's sort of implicit, but then you don't need to support an IPv4 endpoint indefinitely. In that way, it is also a retrofitting of an explicit discovery step. If you step back, this list really reduces to a question of how the respective protocols start. Obviously, there is a bunch of information in a URL that is essential to a protocol interaction. A URL that you decide to actuate represents the start of a protocol interaction and the question is how much information needs to be present in the URL to successfully bootstrap that process. Or, differently stated: How much information about the resolution mechanism is appropriate to include in a URL? If information is included, what is the best means for providing that information? I also think that it would be useful to ask another question, the answer to which is partly in the above taxonomy: How do we manage when the information present is limited, either because the URL already exists, or because we have constraints that encourage the limitation of information that we express in a URI? Or: Is the idea of identifying only in the abstract (i.e., by scheme and authority) and assuming a single protocol, a good choice for every protocol? Protocol Design The question of URL design as protocol design is not one that could be more firmly emphasized. I suspect that most of what we have today we arrived at by a series of accidents. I'm not sure that I believe that we will do better in future, but that's why I think that documents like this can do a lot to help. The next question is then the performance and usability characteristics that result from these choices. For a protocol that decides to embed additional information, that could externalize some of its costs in terms of usability. A sip: URI with transport parameters is fairly user-hostile, but that form is OK when used internally within the protocol (less so when it leaks, and configuring a proxy a SIP UA is awful). A postgresql: URL can happily include that sort of information either because it is copied and pasted more often than typed, or because it is intended for use by experts. A protocol that involves a mandatory discovery step (as opposed to one that is performed opportunistically, in parallel to some sort of default mode), adds the latency of that discovery to resolution. This can complicate the protocol, but it provides opportunities for defining new means of accessing resources without changing the scheme. Retrofitting Into Existing Schemes Happy Eyeballs retrofits a discovery step into a lot of protocols. Running parallel name resolution and connection establishment processes means that you don't have to support both stacks on the server, you shift that responsibility to the client. Racing means that you don't have to pay a latency tax for the new feature. It's a neat hack, but rather expensive. ..onion and friends retrofit a parallel name resolution and authority system into the authority component by stealing a label. There's ongoing discussion about this with the IAB and IESG (the last state I have is that there is renewed enthusiasm for reserving a label at the top level for alternative resolution contexts: .arc). The parallel here is in stealing multiple scheme names for different protocol stacks. ..local is another such land-grab that has problematic implications. The primary one being that it explicitly renders the notion of authority unusable for names in that tree. Some more nit-picky things: Section 1. I think that the point on comparison is only really valuable as a footnote. That https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthority.example%2Fa&data=02%7C01%7Cdthaler%40microsoft.com%7C2a4a4d05564b4ee35ace08d600ecc260%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636697414210041338&sdata=odqUtDQ%2BeKvQYB4dL7t62oxVLujXPedtiVP1w5N2JZA%3D&reserved=0 and https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthority.example%2Fb%2F..%2Fa&data=02%7C01%7Cdthaler%40microsoft.com%7C2a4a4d05564b4ee35ace08d600ecc260%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636697414210051347&sdata=sQ5OYjxZuMrx6pO5jJaroXK%2FZ93KrJ7QVCRkdJ6qLDY%3D&reserved=0 are equivalent isn't really that useful an observation. It might also be the case that /c is equivalent to those two, but that's something that is only really apparent to the authority. And that doesn't cover changes in authority or protocol that might still result in a resource that is considered equivalent by its authority. Factual error: a URI with the https:// scheme is never equivalent to one with a http:// scheme. Though the same content might eventually manifest, the notion of the authority is not the same. This is also an error with the sip/sips comparison; a problem that is at the root of the problems in reconciling sip and sips. Section 2. A better way to present this issue might be to recognize that a URL might represent a resource for any number of purposes and at any layer in a stack. Insert our earlier stackevo discussion around "what is an endpoint", because a URL is intended to identify an endpoint; and the view of what an endpoint is depends on context. Even for the same type of URL. For instance, HTTP URLs are often used at the top of the stack, in a context where higher layers don't exist. Some web URLs fit that description, but there are also uses of HTTP URLs that are only part of another protocol. My thesis here is that, how that URL is consumed is critical to the recommendations we might make. For instance, SIP URLs are used in multiple ways and they are often decorated with all sorts of information about how to reach the destination. On the other hand, TFTP URLs are - as stated - pretty limited in expressiveness. Section 3. The role of discovery mechanisms here is a reasonable breakdown of the options, but I'm finding it hard to connect this with the requirements that might motivate a particular choice. If our ultimate goal is to identify some scenarios in which we can give concrete advice, then this might not be the best structure to support that goal. Section 3.2. The note here about "sometimes assumed that multiple transport protocols would use the same port number" makes me wonder what mechanism might be deployed to support this. In other words, I think that this is a bit of a pipe-dream in RFC 6335. That note and the discussion about parallel port registrations is a distraction here. Similarly, the final note about ephemeral ports doesn't really help the case here and could be removed. The important point is that because port numbers (or other elements of the manner of resolving a locator) could be different upon each instantiation of a service, this adds the necessity to signal that information using the URL. That isn't really compatible with the philosophy of <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FProvider%2FStyle%2FURI.html&data=02%7C01%7Cdthaler%40microsoft.com%7C2a4a4d05564b4ee35ace08d600ecc260%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636697414210051347&sdata=bk7lpLMik3ToentwXtT1HD%2BESeDKOoqFeMvjSfVq9KU%3D&reserved=0>. That suggests either that use of ephemeral ports would only be applicable in cases where the stability of a reference is not critical, or where there is a discovery process such that the port number were not in the URL. That's the key point this makes. I don't find that the talk about RFC 6335 helps with this point. Though the overall discussion of the role of discovery is interesting, it's a badly dated concept and might be better stated with new words. _______________________________________________ Stackevo mailing list Stackevo@iab.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iab.org%2Fmailman%2Flistinfo%2Fstackevo&data=02%7C01%7Cdthaler%40microsoft.com%7C2a4a4d05564b4ee35ace08d600ecc260%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636697414210051347&sdata=G8xFW%2FkTuhBcGvqWfQwW%2FGHjnVZ9Ees2aUTjycD%2Fruo%3D&reserved=0--- End Message ---
- [Stackevo] an agenda for Wednesday's meeting Brian Trammell (IETF)
- Re: [Stackevo] an agenda for Wednesday's meeting Eliot Lear
- Re: [Stackevo] an agenda for Wednesday's meeting Dave Thaler
- Re: [Stackevo] an agenda for Wednesday's meeting Brian Trammell (IETF)
- Re: [Stackevo] an agenda for Wednesday's meeting Dave Thaler
- Re: [Stackevo] an agenda for Wednesday's meeting Aaron Falk
- Re: [Stackevo] an agenda for Wednesday's meeting Brian Trammell (IETF)
- Re: [Stackevo] an agenda for Wednesday's meeting Cindy Morgan
- Re: [Stackevo] an agenda for Wednesday's meeting Aaron Falk