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. - 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. - I am not sure why "match other locators" (in the GRASP document) is a useful goal. 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... - 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). 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 -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
