Subject: Re: [Anima] Need WG input: Alexy Melnikov's suggestion on GRASP

From: Toerless Eckert <[email-masked]>
Date: Fri, 2 Jun 2017 13:32:07 +0200

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-masked]> wrote:
> > 
> >     >> Brian E Carpenter <[email-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Jun 2017 16:21:46 +1200

>   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.
 
>   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?

>   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.

>   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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 6 Jun 2017 22:31:44 +0200

> 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".

> 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 of non-uniform objects...

> 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

-- 
---
[email-masked]