On 02/06/2017 23:32, Toerless Eckert wrote: > Alexey wrote: >> I suggest inclusion of optional transport protocol here to match other >> locators and to follow best practices for not encoding transport >> information in URIs. > >>From my side; > - 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. > - 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. > - I am not sure why "match other locators" (in the GRASP document) is a > useful goal. Uniform parsing? > The other locators provide a transport endpoint locator (ipv*addr/fqdn, > proto, port), > URI provides formost a > layer 4 "protocol" (eg: http: or the like). Its > like trying to fit > apple and battleships into one class of O_*_WORDS... Actually I think URIs (not URLs) are more abstract than that: they can be anything you can imagine. > - 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. 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
