Re: [dispatch] Tiny update to RFC 3405

[Timothy Mcsweeney <[e-mail]>]

text version:
Martin, 

>The current BCP 35 doesn't contain such requirements, and
>therefore doesn't make any sense.

That's right, BCP doesn't contain such requirements.
Whether or not makes sense to you is immaterial.
Thank you for helping me state my case.

Tim


> On 07/13/2020 9:33 AM Timothy Mcsweeney <[e-mail]> wrote:
> 
> 
> Martin,
> 
> >The current BCP 35 doesn't contain such requirements, and 
> >therefore doesn't make any sense.
> 
> That's right, BCP doesn't contain such requirements.
> Whether or not makes sense to you is immaterial.
> Thank you for helping me state my case.
> 
> Tim
> 
> 
> 
> 
> 
> > On July 12, 2020 at 7:43 AM "Martin J. Dürst" < [e-mail]> wrote:
> > 
> > 
> > On 10/07/2020 04:43, Timothy Mcsweeney wrote:
> > > You're talking about the [ 10 < ]" rel="noopener" target="_blank" data-mce-href="https://tools.ietf.org/html/rfc3405#ref-10>]">https://tools.ietf.org/html/rfc3405#ref-10>] (https://tools.ietf.org/html/rfc3405#ref-10)
> > > reference in section 3.1.1 in 3405
> > > < https://tools.ietf.org/html/rfc3405#section-3.1.1> and when I click on the
> > > reference it sends me right to BCP35 < " rel="noopener" target="_blank" data-mce-href="https://tools.ietf.org/html/bcp35>">https://tools.ietf.org/html/bcp35> (https://tools.ietf.org/html/bcp35).
> > When I look at
> > 
> > >>>>
> > [10] Petke, R. and I. King, "Registration Procedures for URL Scheme
> > Names", BCP 35, RFC 2717, January 1999.
> > >>>>
> > it has two links, one for BCP 35 (which now redirects to something else
> > which doesn't actually match the reference data) and one for RFC 2717
> > (which matches the original reference, including author and date of
> > publication).
> > 
> > RFC 2717 then says:
> > 
> > >>>>
> > 2.2 The IETF Tree
> > 
> > The IETF tree is intended for URL schemes of general interest to the
> > Internet community. The tree exists for URL schemes that require a
> > substantive review and approval process. It is expected that
> > applicability statements for particular applications will be
> > published from time to time that recommend implementation of, and
> > support for, URL schemes that have proven particularly useful in
> > those contexts.
> > >>>>
> > 
> > > >The reason for the update is that IETF tree registrations *are* required.
> > Yes, and the closest to that ("URL schemes of general interest to the
> > Internet community", "require a substantive review and approval
> > process") we currently have is permanent registration, so that's where
> > Ted's proposal (which I fully support) comes from.
> > 
> > > That is now, scheme registration is required, including provisionals. See, no bug.
> > No. That there's a link somewhere doesn't mean you can interpret things
> > any which way. The reference you follow (in one specific way) comes from
> > 
> > >>>>
> > 3.1.1 Only Schemes in the IETF Tree Allowed
> > 
> > In order to be inserted into the URI.ARPA zone, the subsequent URI
> > scheme MUST be registered under the IETF URI tree. The requirements
> > for this tree are specified in [10].
> > >>>>
> > 
> > This means that the reference is for defining the requirements of the
> > IETF URI tree. The current BCP 35 doesn't contain such requirements, and
> > therefore doesn't make any sense. The old BCP 35 (RFC 2717) is clear,
> > but is no longer in force. As a consequence, we have a dangling
> > reference (IETF Tree is no longer defined in a valid IETF spec). We
> > cannot just say "let's assume this means whatever suits me best" or "by
> > chance there's a link (out of two) that leads to a spec that includes
> > something that suits me", but we have to recognize that we have a
> > problem with the spec (when updating BCP 35, its authors forgot to
> > update RFC 3405), and have to fix that.
> > 
> > And the fix that Ted is proposing is the fix that is closest to the
> > original intent, and takes into account the reason for the original
> > restriction.
> > 
> > Regards, Martin.
> > 
> > 
> > > Tim
> > > 
> > > 
> > > 
> > > 
> > > > On July 9, 2020 at 3:09 PM Ted Hardie < [e-mail]> wrote:
> > >> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < [e-mail]
> > >> <mailto: [e-mail]>> wrote:
> > >>
> > >> __
> > >> Ted,
> > >>
> > >> Section 2 (Updated Requirements) of your draft says:
> > >> "All registrations in URI.ARPA MUST be for schemes which are permanent
> > >> registrations, as they are described in BCP 35."
> > >>
> > >> I take that as:
> > >> We must update this because permanent registrations are not required.
> > >> Otherwise there is no reason for an update.
> > >>
> > >>
> > >> The reason for the update is that IETF tree registrations *are* required.
> > >> That effectively closes the registry, without the community having made the
> > >> affirmative decision to do so. I want to fix that bug.
> > >>
> > >> I currently think that the closest replacement to the IETF tree would be
> > >> permanent registration and that we should fix this by requiring that. But I'm
> > >> happy to see a clear draft espousing some other way of fixing the bug; if you
> > >> have an idea about that, please write the draft.
> > >>
> > >> regards,
> > >>
> > >> Ted
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> If you are going to argue both sides, my draft and I will just stay out of
> > >> it. Here is your pointer.
> > >> https://www.ietf..org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2
> > >> < https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2>
> > >>
> > >>
> > >> Tim
> > >>
> > >>
> > >>> On July 9, 2020 at 11:57 AM Ted Hardie < [e-mail]
> > >>> <mailto: [e-mail]>> wrote:
> > >>>
> > >>> Howdy,
> > >>>
> > >>> On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < [e-mail]
> > >>> <mailto: [e-mail]>> wrote:
> > >>>
> > >>> __
> > >>> Hi Ben,
> > >>>
> > >>> Thanks for the heads up on the deadline,
> > >>>
> > >>> I am a little surprised that you are choosing to discuss this at all
> > >>> with pending
> > >>> registrations and I obviously disagree with that. But if there are
> > >>> more than 5 people besides Ted that think the current rules for
> > >>> provisionals in the zone
> > >>>
> > >>>
> > >>> I don't think I've seen anyone but you argue that the current rules
> > >>> permit provisionals in the zone; if I have missed others reading the
> > >>> rules that way, I'd appreciate a pointer.
> > >>>
> > >>> I think, though, that the key thing is to get some clarity on what the
> > >>> rules should be after the elimination of the IETF tree. Since you
> > >>> obviously disagree with my proposal, having your alternative spelled in a
> > >>> draft does seem like the best way forward. Wherever dispatch sends the
> > >>> question would then have two clear proposals to choose between.
> > >>>
> > >>> regards,
> > >>>
> > >>> Ted Hardie
> > >>>
> > >>> are
> > >>> too open and need to be further constrained then I will submit a
> > >>> draft that does
> > >>> just that before the deadline.
> > >>>
> > >>>
> > >>>> On July 8, 2020 at 10:36 PM Ben Campbell < [e-mail]
> > >>>> <mailto: [e-mail]>> wrote:
> > >>>>
> > >>>> Hi Tim,
> > >>>>
> > >>>> Do you plan to submit an internet-draft? If so, please be advised
> > >>>> that the deadline for drafts prior to IETF108 is this coming Monday
> > >>>> (7/13). If you submit a draft prior to the deadline, we can consider
> > >>>> it along with Ted’s draft (either on the list or possibly in the
> > >>>> IETF108 DISPATCH meeting).
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Ben.
> > >>>>
> > >>>>> On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < [e-mail]
> > >>>>> <mailto: [e-mail]>> wrote:
> > >>>>>
> > >>>>> Hi All,
> > >>>>>
> > >>>>> Updating RFC3405 will necessarily require changes to RFC3401 as
> > >>>>> stated in its
> > >>>>> introduction. "This document will be updated and or obsoleted when
> > >>>>> changes
> > >>>>> are made to the DDDS specifications."
> > >>>>>
> > >>>>> We are now changing two RFCs so I don't think this fits as a
> > >>>>> "simple administrative".
> > >>>>>
> > >>>>> But, I may have a work around that is simple and also solves the
> > >>>>> provisional registration problem as stated by Ted. I could have
> > >>>>> ready in a day or so.
> > >>>>>
> > >>>>> Tim
> > >>>>>> On July 7, 2020 at 3:34 AM "Martin J. Dürst" <
> > >>>>>> [e-mail] <mailto: [e-mail]..jp>> wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>> On 23/06/2020 07:51, Ben Campbell wrote:
> > >>>>>>> Hi Everyone,
> > >>>>>>>
> > >>>>>>> The ART ADs have reminded the chairs that our charter allows us
> > >>>>>>> to adopt “simple administrative” work such as IANA registration
> > >>>>>>> documents. This draft seems to fit squarely in that category..
> > >>>>>>> Does anyone see a reason we shouldn’t just adopt it, with the
> > >>>>>>> expectation of going immediately to WGLC? (The last-call timeline
> > >>>>>>> is the same either way, either 2 weeks WGLC and 2 weeks IETF LC
> > >>>>>>> for a working group draft, or 4 weeks IETF LC for an AD sponsored
> > >>>>>>> draft.)
> > >>>>>>
> > >>>>>> Triggered by the recent discussion, I had a look at Ted's draft
> > >>>>>> and the
> > >>>>>> mail up to today. To me, both AD sponsored and Dispatch WG look
> > >>>>>> reasonable, with a slight preference for the former (if asked to
> > >>>>>> express
> > >>>>>> such a preference).
> > >>>>>>
> > >>>>>> With respect to "pending registrations", I do not think these are
> > >>>>>> relevant, in particular because the thing in question isn't
> > >>>>>> actually a
> > >>>>>> scheme, as discussed on the relevant list.
> > >>>>>>
> > >>>>>> I have one comment: The abstract currently reads
> > >>>>>> "This document removes references to the IETF tree of URI
> > >>>>>> registrations
> > >>>>>> for registrations in URI.ARPA.". I found this hard to read, and I
> > >>>>>> guess
> > >>>>>> it's because of the "registrations for registrations" piece.
> > >>>>>> Unless one
> > >>>>>> is very familiar with the matter at hand, it's easy to think that
> > >>>>>> both
> > >>>>>> occurrences of "registration" are referencing the same thing.
> > >>>>>> While I'm
> > >>>>>> at it, it would also be good if the abstract mentioned something
> > >>>>>> positive. I think a less normative version of (the single sentence
> > >>>>>> that
> > >>>>>> is) Section 2 would serve well as the abstract.
> > >>>>>>
> > >>>>>> Regards, Martin.
> > >>>>>>
> > >>>>>>> Thanks!
> > >>>>>>>
> > >>>>>>> Ben (as co-chair)
> > >>>>>>>
> > >>>>>>>> On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail..com
> > >>>>>>>> <mailto: [e-mail]>> wrote:
> > >>>>>>>>
> > >>>>>>>> Howdy,
> > >>>>>>>>
> > >>>>>>>> This is one the shortest drafts I've ever written:
> > >>>>>>>> https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/
> > >>>>>>>> < https://datatracker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/>
> > >>>>>>>> <
> > >>>>>>>> https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/>
> > >>>>>>>> .. Basically, RFC 3405 used to require that registrations in
> > >>>>>>>> URI.ARPA be from the "IETF Tree". That tree was deprecated after
> > >>>>>>>> the document was published... As it happens, there are very few
> > >>>>>>>> registrations in URI.ARPA, so we did not catch it and fix it
> > >>>>>>>> before now.
> > >>>>>>>>
> > >>>>>>>> This draft updates RFC 3405 to require "permanent" scheme
> > >>>>>>>> registrations. The salient bit is this:
> > >>>>>>>>
> > >>>>>>>> All registrations in URI.ARPA MUST be for schemes which are
> > >>>>>>>> permanent
> > >>>>>>>> registrations, as they are described in BCP 35.
> > >>>>>>>>
> > >>>>>>>> I'm hoping for a quick dispatch of this, but happy to discuss.
> > >>>>>>>>
> > >>>>>>>> regards,
> > >>>>>>>>
> > >>>>>>>> Ted Hardie
> > >>>>>>>> _______________________________________________
> > >>>>>>>> dispatch mailing list
> > >>>>>>>> [e-mail] <mailto: [e-mail]>
> > >>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> _______________________________________________
> > >>>>>>> dispatch mailing list
> > >>>>>>> [e-mail] <mailto: [e-mail]>
> > >>>>>>> https://www.ietf.org/mailman/listinfo/dispatch
> > >>>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Prof. Dr.sc. Martin J. Dürst
> > >>>>>> Department of Intelligent Information Technology
> > >>>>>> College of Science and Engineering
> > >>>>>> Aoyama Gakuin University
> > >>>>>> Fuchinobe 5-1-10, Chuo-ku, Sagamihara
> > >>>>>> 252-5258 Japan
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> dispatch mailing list
> > >>>>>> [e-mail] <mailto: [e-mail]>
> > >>>>>> https://www.ietf.org/mailman/listinfo/dispatch
> > >>>>> _______________________________________________
> > >>>>> dispatch mailing list
> > >>>>> [e-mail] <mailto: [e-mail]>
> > >>>>> https://www.ietf.org/mailman/listinfo/dispatch
> > >>>>
> > >>>
> > >>> _______________________________________________
> > >>> dispatch mailing list
> > >>> [e-mail] <mailto: [e-mail]>
> > >>> https://www.ietf.org/mailman/listinfo/dispatch
> > >>>
> > >>
> > > 
> > > _______________________________________________
> > > dispatch mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dispatch
> > > 
> > --
> > Prof. Dr.sc. Martin J. Dürst
> > Department of Intelligent Information Technology
> > College of Science and Engineering
> > Aoyama Gakuin University
> > Fuchinobe 5-1-10, Chuo-ku, Sagamihara
> > 252-5258 Japan