Subject: [art] BCP190

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Jul 2019 19:15:55 -0400

I think BCP190 is the right thing for protocols that are added to a web server.
BCP190 is out of scope for protocols that define an entire web server.

Count me in for a side meeting.

Grüße, Carsten

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Jul 2019 23:57:42 -0400

> BCP190 is out of scope for protocols that define an entire web server.

Without weighing in on whether this statement is something I agree with, 
I want to point out that it isn't applicable to the topic at hand: 
discussions in TRANS have specifically referred to the origins that CT 
logs are hosted on as "multi-tenant."

/a

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 23 Jul 2019 06:25:39 -0400

Hi Adam,

On Jul 22, 2019, at 23:57, Adam Roach <[email-masked]> wrote:
> Without weighing in on whether this statement is something I agree with, I want to point out that it isn’t applicable to the topic at hand: discussions in TRANS have specifically referred to the origins that CT logs are hosted on as "multi-tenant."

Apparently, I need to read up on TRANS.  

But given that we are now discussing BCP190, I wouldn’t mind if you (and other people who have thought a lot about BCP190) could take a position on my statement (which includes another half, i.e., that BCP190 is alive and well in the other cases).

Grüße, Carsten

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 11:03:00 -0400

> But given that we are now discussing BCP190, I wouldn’t mind if you (and other people who have thought a lot about BCP190) could take a position on my statement (which includes another half, i.e.,…

While I do have opinions here, I'm presently trying to get input from 
the community rather than influence the conversation. I may weigh in on 
the topic later; but for now, I don't want to push one way or the other.

/a

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Jul 2019 16:21:07 +0100

Hiya,

> the topic later; but for now, I don't want to push one way or the other.

On the general topic, I don't think it's realistic nor wise
to try always strictly enforce BCPs. BCP107 is a fine case
in point - attempts by the SEC ADs over the years (including
this former instance of the animal;-) haven't IMO made the
Internet better in most cases - some yes, but mostly not, and
while the general guidance is correct, being too strict with
it is not, in the end, a good plan.

Specific to trans, there are not millions of CT logs in the
world, and nor should there be and nor will there be. We're
talking a handful. So I do not think the problems that BCP190
attempts to mitigate apply here really.

So, in this case, I'd say give 'em a pass and let the current
deployed scheme continue to be used. IIRC URL handling is
pretty much as was done in the deployed and very widely used
RFC6962, which has made the Internet better in a fairly
significant manner IMO.

Adding a note that they're being a bit naughty would be fine.

Cheers,
S.

Cheers,
S.

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 11:40:06 -0400

> it is not, in the end, a good plan.

I think you're correct here. I also think that it's important that we 
agree where these BCPs get things wrong, and adjust them to reflect the 
conclusions the community has reached. If BCP 107 needs occasional 
overrides, a minor revision of that document to explain that point would 
seem in order, so as to save heartburn for all parties further down the 
road.

I'll repeat what I've said to the TRANS chairs on this topic: if we can 
get an agreement in principle on the ART mailing list that BCP 190 is 
too strict and needs to be updated to allow the kinds of exceptions 
envisioned by TRANS, then I'm willing to clear as soon as consensus in 
support of that proposition becomes evident, even in advance of a draft 
that proposes the concrete updates to the BCP. Absent that, the decision 
on the TRANS mailing list looks too much like one working group 
discarding established IETF consensus without input from the appropriate 
stakeholders.

/a

---

From: "Devon O'Brien" <[email-masked]>
Date: Tue, 23 Jul 2019 09:20:44 -0700

The decision we've arrived at is to address the open DISCUSS so we can move
forward with RFC 6962-bis, not to disregard IETF consensus. This was the
driving force behind getting time yesterday during ART with in-person and
remote participation by many of the contributing stakeholders from TRANS.
Ensuring wide and open representation in these discussions is also why I'm
hesitant to rely on an ad-hoc side meeting at IETF 105 that precludes
remote participation, as this will likely lead to incomplete representation
and/or a complete rehashing on-list.

The TRANS discussion as well as the points summarized in the 105 ART slides
[1] present a summary of the alternatives considered and why many in TRANS
feel they are not appropriate in the context of CT. If there is a specific
concern with the 6962-bis draft 31 approach [2] beyond the stated
non-conformity with BCP 190, I would really like to hear it so we can make
a better-informed decision and better weigh the alternatives.

If there are not concrete concerns to that effect, I'd like to better
understand the route forward. It seems like we can either:
1) Acknowledge BCP 190 non-conformity within RFC 6962-bis with a brief
description and rationale
2) Begin the process to edit BCP 190 such that RFC 6962-bis is no longer
out of compliance using pre-draft-32 language

Due in part to the aforementioned delays incurred throughout RFC 6962-bis's
process, including dropping it down to Experimental track, several members
of TRANS appear to not be keen on holding this up for an attempt to address
general concerns with BCP 190 prescriptiveness. This sentiment was echoed
by some in the mic-line at yesterday's ART session, but it was too brief to
fully address comments from attendees and might not have allowed for folks
to raise compelling counter-arguments. Not being an expert here, I'd like
input on which is the best approach to pursue.

-Devon

[1]
https://datatracker.ietf.org/doc/slides-105-dispatch-rfc-6962-bis-and-bcp-190/
[2] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/31/

On Tue, Jul 23, 2019 at 8:40 AM Adam Roach <[email-masked]> wrote:

> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 12:33:28 -0400

> On Jul 23, 2019, at 12:20, Devon O'Brien <[email-masked]> wrote:
> 
> The TRANS discussion as well as the points summarized in the 105 ART slides [1] present a summary of the alternatives considered and why many in TRANS feel they are not appropriate in the context of CT.

As I pointed out in the room, the objection to using .well-known was based on a misunderstanding on the part of the TRANS working group. It cited not just an obsoleted document; it cited the exact text that was removed by its successor document to make room for things like CT.

/a

---

From: "Devon O'Brien" <[email-masked]>
Date: Tue, 23 Jul 2019 09:47:44 -0700

Yes, and thank you very much for that clarification. I was, however, hoping
to hear if there are specific criticisms of the approach in 6962-bis draft
31 that would warrant altering the CT ecosystem or risk the
non-implementation of 6962-bis. Yesterday, there were multiple comments of
"overbroadness" of BCP 190, and while I'm not sufficiently equipped to
address these general concerns, I was looking to see if there is a
technically sound reason to alter CT from the existing deployed mechanism,
which is also described in pre-draft 32 language of 6962-bis.

Am I to take your position as an endorsement of altering CT to use
/.well-known/ or is it simply a criticism of our (flawed) analysis of
alternatives?

On Tue, Jul 23, 2019 at 9:33 AM Adam Roach <[email-masked]> wrote:

> > The TRANS discussion as well as the points summarized in the 105 ART
> slides [1] present a summary of the alternatives considered and why many in
> TRANS feel they are not appropriate in the context of CT.
>
> As I pointed out in the room, the objection to using .well-known was based
> on a misunderstanding on the part of the TRANS working group. It cited not
> just an obsoleted document; it cited the exact text that was removed by its
> successor document to make room for things like CT.
>
> /a
>

---

From: Andrew Ayer <[email-masked]>
Date: Tue, 23 Jul 2019 09:53:02 -0700

On Tue, 23 Jul 2019 12:33:28 -0400
Adam Roach <[email-masked]> wrote:

> > The TRANS discussion as well as the points summarized in the 105
> > ART slides [1] present a summary of the alternatives considered and
> > why many in TRANS feel they are not appropriate in the context of
> > CT.
> 
> As I pointed out in the room, the objection to using .well-known was
> based on a misunderstanding on the part of the TRANS working group.
> It cited not just an obsoleted document; it cited the exact text that
> was removed by its successor document to make room for things like CT.

The other reason that TRANS rejected .well-known is because .well-known
is often locked down in deployment environments.

We tried using .well-known with
draft-ietf-trans-gossip. Google had to put their implementation at
https://www.gstatic.com/ct/gossip/ct/v1/sth-pollination rather than
under .well-known.

In other words, mandating .well-known is a greater imposition on
URI namespace owners in practice than what
draft-ietf-trans-rfc6962-bis-31 does.  This is further evidence that
BCP 190 needs revision.

Regards,
Andrew

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 14:06:09 -0400

> /.well-known/ or is it simply a criticism of our (flawed) analysis of 

I think moving under .well-known is a valid solution to the situation at 
hand. It's far from my preferred one: the use of URLs in CT is a poster 
child for why URI templates (RFC 6570) were developed, and I think that 
solution fits this problem perfectly. However, I also recognize that 
such a change at this point in the process is probably more disruptive 
than simply moving under the namespace that has been carved out for uses 
that want to specify names, paths, and parameters in the way that CT does.

I also think it would be valid to get the rest of the community on-board 
with principled changes to the provisions of BCP 190, if that's 
achievable. That seems to be the path you've chosen. The goal here 
remains finding a cross-IETF consensus about whether what TRANS is 
currently proposing to do is reasonable, given that previous discussions 
concluded that it is not.

/a

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Jul 2019 14:16:23 -0400

Regarding URL Templates -- FWIW, there are many libraries and a well-defined test suite available; see:
  https://github.com/uri-templates/uritemplate-spec/wiki/Implementations
  https://github.com/uri-templates/uritemplate-testf

Cheers,

> On 23 Jul 2019, at 2:06 pm, Adam Roach <[email-masked]> wrote:
> 
>> Am I to take your position as an endorsement of altering CT to use /.well-known/ or is it simply a criticism of our (flawed) analysis of alternatives?
> 
> I think moving under .well-known is a valid solution to the situation at hand. It's far from my preferred one: the use of URLs in CT is a poster child for why URI templates (RFC 6570) were developed, and I think that solution fits this problem perfectly. However, I also recognize that such a change at this point in the process is probably more disruptive than simply moving under the namespace that has been carved out for uses that want to specify names, paths, and parameters in the way that CT does.
> 
> I also think it would be valid to get the rest of the community on-board with principled changes to the provisions of BCP 190, if that's achievable. That seems to be the path you've chosen. The goal here remains finding a cross-IETF consensus about whether what TRANS is currently proposing to do is reasonable, given that previous discussions concluded that it is not.
> 
> /a
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Larry Masinter <[email-masked]>
Date: Tue, 23 Jul 2019 12:47:55 -0700

> I'll repeat what I've said to the TRANS chairs on this topic: if we can
get an
> agreement in principle on the ART mailing list that BCP 190 is too strict
and
> needs to be updated to allow the kinds of exceptions envisioned by TRANS,

I'm not sure it's BCP 190 that is too strict, but the IESG's DISCUSSes are
too strict in their interpretation of it and the wisdom of treating
non-conformity with a BCP as somehow being disallowed in an
Experimental status specification.

If you read BCP 190, it doesn't consistently state requirements
for conformance with it. The abstract provides what I thought
were sufficient context:

   While it is common for schemes to further delegate their
   substructure to the URI's owner, publishing independent standards
   that mandate particular forms of URI substructure is inappropriate,
   because that essentially usurps ownership.  This document further
   describes this problematic practice and provides some acceptable
   alternatives for use in standards.

This seems to focus  the intended scope to "publishing independent
standards" 
and that the consequence of non-conformance would be something that
might be "problematic" if not completely "inappropriate" because
it "essentially usurps ownership" where "ownerships is defined with a
 (normative) reference to
https://www.w3.org/TR/2004/REC-webarch-20041215/#uri-ownership

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2019 16:13:50 -0400

> Experimental status specification.

The TRANS working group is chartered to eventually progress this 
specification from Experimental to Standards Track. What do you believe 
happens at that point?

/a

---

From: Melinda Shore <[email-masked]>
Date: Tue, 23 Jul 2019 16:26:02 -0400

> specification from Experimental to Standards Track. What do you believe

Yes, I think we do need to see this resolved.

Melinda

-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
                     34C0 DFB8 9172 9A76 DB8F

---

From: Larry Masinter <[email-masked]>
Date: Tue, 23 Jul 2019 14:21:50 -0700

> specification from Experimental to Standards Track. What do you believe

Since the topic of URL ownership straddles multiple groups in multiple organizations (ARTWG, HTTPBISWG, IESG in IETF, W3CTAG in W3C, UASG in ICANN)
It's hard to be optimistic, but ideally the results of the Experimental 
implementations will be useful in guiding an update to BCP190 or even
a broader set of guidelines for URL use in APIs.

In particular, all of the complexity in HAL
https://en.wikipedia.org/wiki/Hypertext_Application_Language
 https://tools.ietf.org/html/draft-kelly-json-hal-08 

seems to focus on reducing operational difficulties or administrative problems by adding
another level of indirection.

In particular, I might suggest the Note added to the preface of the Experimental specification should solicit feedback on these kinds of open issues.

---

From: "Manger, James" <[email-masked]>
Date: Wed, 24 Jul 2019 01:10:46 +0000

> From: art <[email-masked]> On Behalf Of Mark Nottingham
>

Unfortunately, RFC6570 "URI Template" is not fit for purpose.

It doesn't support the basic feature of allowing a site (template author) to choose its own names for optional query parameters. For instance, if a spec defines variables "searchTerms", "startPage", and "language"; a site can't chose to put these in query parameters named "q", "pg", and "lang", that are omitted when no value is defined. {?searchTerms,startPage,language} will omit undefined variables; ?q={searchTerms}&pg={startPage}&lang={language} will use the site's names. A site cannot have both with RFC6570.

It also tramples on the meaning of commas; giving them meaning that the URI spec never did. For instance, /pay/{amount},{to},{desc} looks reasonable, but in fact if the "amount" is given as an array its expansion will include the reserved "," character so it can override the "to" field.

--
James Manger