Re: [art] Last Call for Comments: draft-nottingham-rfc7320bis (BCP 190 update)

Thanks for bringing that up again, Larry! I recall seeing that message 
and having a hard time parsing out the point you were making or deducing 
what resultant changes you'd like to see to BCP 190. I meant to return 
to it later to puzzle out your exact meaning, but it got away from me. I 
apologize.

Thanks for adding concrete examples; looking to them for clarification...

It appears that draft-kelly-json-hal is using URIs exactly as expected 
(that is, the _thing_ being talked about is exactly the _thing_ the URI 
has been assigned to by the site administrator), albeit with some 
interesting HTTP-specific protocol stuff that uses Content-Type to 
change the response body from information to metainformation. There's 
certainly some HTTP-related discussion to be had here about the wisdom 
of overloading the semantics of Content-Type in this way, but it doesn't 
seem to bear on the naming question. Correct me if I've simply found the 
wrong part of this document.

I dug through draft-ietf-core-coral and couldn't quite find any 
mechanism that seems to align with the words in your statement below. 
But then again, it's a pretty big draft, and you didn't cite any 
particular behavior in particular, so I might have missed the section 
you have in mind. For what its worth, the URI handling that I see in 
that document is based on the provisioning of a (server-controlled) 
starting-point URI into clients, and then using a document at that 
endpoint as a roadmap for all the other URIs used by the application. 
This seems entirely compliant with both BCP 190 as currently written and 
with the proposed BCP 190 currently under discussion. I see nothing to 
"take into account" here, as the draft's approach is already in 
accordance with BCP 190 (and, in fact, it was one of the solutions that 
I encourage TRANS to pursue).

As before, I'm trying not to take a position on any given issue here, so 
I don't intend to argue for or against the point you're making -- I'm 
just looking for clarity on what you're trying to say, ideally in a way 
that is understandable to the community and (assuming the community 
agrees) actionable for the draft author.

I would propose that the easiest way to make progress is to send 
concrete suggestions to this mailing list detailing text that you would 
like to see added/revised/removed from the current draft. If you find it 
easier, you may wish to submit a PR against 
https://github.com/mnot/I-D/blob/gh-pages/rfc7320bis/draft.md and post a 
link to that PR to this mailing list. If not, email with OLD/NEW 
sections would serve the purpose just fine.

Thanks!

/a

On 10/16/19 2:10 PM, Larry Masinter wrote:
> On 8/21/2019 at 7:50 AM I wrote
>
> An update to BCP 190 should take into account the fact that there is not a consensus for the "best" of various "current practice" for avoiding the URL squatting identified (namely using a hypermedia format to let the server control the URL format completely rather than the API control the URL syntax and making the client do string processing.
>
> But didn't see a reply.
>
> If you want links, link to draft-hartke-t2trg-coral and draft-kelly-json-hal as two examples of current practice for which the "best" way hasn't shaken out.
>
> Larry
> --
> https://LarryMasinter.net
>
>
>
> -----Original Message-----
> From: Larry Masinter <masinter@gmail.com> On Behalf Of Larry Masinter
> Sent: Wednesday, August 21, 2019 7:50 AM
> To: 'Adam Roach' <adam@nostrum.com>; 'John C Klensin' <john-ietf@jck.com>; 'Mark Nottingham' <mnot@mnot.net>
> Cc: 'Jacob Hoffman-Andrews' <jsha@letsencrypt.org>; 'Devon O'Brien' <devon.obrien@gmail.com>; 'ART Area' <art@ietf.org>
> Subject: RE: [art] Call for Consensus: Re: On BCP 190
>
> Just back from an August vacation, apologies for brevity IMHO An update to BCP 190 should take into account the fact that there is not a consensus for the "best" of various "current practice" for avoiding the URL squatting identified (namely using a hypermedia format to let the server control the URL format completely rather than the API control the URL syntax and making the client do string processing.
>
>
> As far as process goes, I think it's ok to drop the DISCUSS in
>   question because it is Experimental and not Standards track.
>
>
> As  Carsten Bormann <cabo@tzi.org> wrote  Sunday, July 28, 2019 1:43 AM
> Re: [art] On BCP 190
>
>> On Jul 28, 2019, at 08:26, Larry Masinter <LMM@acm.org> wrote:
>>> Now, why JSON-HAL is still an expired  Internet Draft is a puzzle.
>> (Slightly, but not completely off-topic:)
>>
>> Probably because there are multiple ways to skin this cat and we never
>> tried to converge on one.
>>
>> As a data point, for the applications in the CoRE working group, we
>> have mostly been able to avoid BCP190-style arguments by using
>> /.well-known, mainly because simple devices only tend to have one
>> service offered directly under / and because IoT device platforms tend
>> to provide the application developer full control over the URI space.
>> /.well-known/core provides a discovery mechanism for the entry point URIs
> actually offered by a server.
>> For where this is not enough, the WG has just last week adopted CoRAL
>> (not yet resubmitted as draft-ietf, so you can find it at
>> draft-hartke-t2trg-coral) as our idea of a hypermedia format like HAL.
>> Up to now, we tried to make everything work with RFC 6690 link format,
>> but that has too many idiosyncrasies that started to get in the way of a
> long-term way forward.
>
>
>
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art