On Tue, Jun 06, 2017 at 04:21:46PM +1200, Brian E Carpenter wrote: > > - I do not understand what "best practices for not encoding transport > > information in URIs" > > is. An example would be great. If > > http://example.com:1234/something-like-this is > > undesirable because it encodes a transport port number in the URI, then > > there is a whole universe > > not following "best practices for not encoding...". Else i wouldn't know > > what it means. > > That's what it means. I've always hated the :1234 because it clashes with > literal IPv6 addresses in URLs (hence RFC2732). It was bad luck really, > because > URI syntax and IPv6 address syntax were developed at the same time by > different > teams. Obviously, Tim Berners-Lee and I didn't talk enough, although our > offices > were about 20 metres apart at the time.
Great history. And good job with 2732. I could start ranting about IPv6 being inappropriate to remember literal addresses, but won't -). Nevertheless: it doesn't anwer what is the "best practice for NOT encoding transport information in URIs". > > - Aka: I have not seen common data models / user interfaces where IP > > version, protocol or port > > are specified together with URIs (but no in URI). If thats the > > recommended pracice i'd love > > pointer to prior reference doing that. > > That's for the ART people to answer, so I have cc'ed Alexey. Ok. Let me do explicit recipient addressing in the 822 Subject: line to increase the likelyhood of eliciting a response to that. > > - I am not sure why "match other locators" (in the GRASP document) is a > > useful goal. > > Uniform parsing? Uniform parsing of non-uniform objects... > > - So, i would really like an example i would really bother about instead of > > idontcareschema:irrelevant.example ;-) > > > > - If others feel that it "looks" inconsistent enough to bother but that > > there is no good example > > why / where / how we'd need those parameters for URI locators, then maybe > > just emphasize the > > difference between URI and the other locators by renaming those other > > locators to one class: > > O_IPV4_TE_LOCATOR, O_IPV6_TE_LOCATOR and O_FQDN_TE_LOCATOR (TE = > > Transport Endpoint). > > I agree that there's a difference of nature between them and a URI (I = > Identifier) > but I don't think renaming really helps. What I have put in the -13 draft is > Alexey's suggestion but with the option of a null protocol & port, since > I don't think https://example.com/anima/intent really needs either. Sure. Lets see if Alexey can provide an example from some other protocol/environment where the transport parameter (eg: port) is explicitly signaled in an API/GUI beside the URI as opposed to being in the URI. Cheers Toerless > Brian > > > > > On Thu, Jun 01, 2017 at 03:22:30PM +1200, Brian E Carpenter wrote: > >> On 31/05/2017 04:37, Michael Richardson wrote: > >>> Brian E Carpenter <[email protected]> wrote: > >>> > >>> >> Brian E Carpenter <[email protected]> wrote: > I have > >>> >> started the process of going through IESG comments on the GRASP > > >>> >> draft. Where something is editorial or obviously > >>> non-controversial, I > >>> >> > will not ask for input. But I do need input on some things, and > >>> here > >>> >> is > the first. Please answer quickly; no answer will be taken to > >>> >> mean that > you don't care... > >>> >> > >>> >> > Alexy wrote: >>> uri-locator = [O_URI_LOCATOR, text] > >>> >> >>> > >>> >> >>> I suggest inclusion of optional transport protocol here to > >>> match > >>> >> >>> other locators and to follow best practices for not encoding > >>> >>> > >>> >> transport information in URIs. > >>> >> > >>> >> > That would become uri-locator = [O_URI_LOCATOR, text, > >>> >> transport-proto, > port-number] > >>> >> > >>> >> > Opinions? Objections? > >>> >> > >>> >> If the resource is really at https://example.com:9943/my/path > >>> >> > >>> >> what would text, transport-proto be? > >>> > >>> > "https://example.com:9943/my/path";, Null, Null perhaps. > >>> > >>> > Also of course see the thread on Adam Roach's comment. > >>> > >>> okay, then give me an example where it wouldn't be null and null? > >> > >> funnyschema:funny.stuff > >> > >> Who knows what proto and port might be appropriate? I'll buy > >> Alexy's suggestion, because it really costs nothing. > >> > >> Brian > >> > >> _______________________________________________ > >> Anima mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
