[Cbor] Re: Normative vs. informative (Re: cbor-edn-literals should introduce the whole diagnostic notation)

[Joe Hildebrand <[e-mail]>]

Thanks, Orie.

If we do embark on the larger set of doc changes that Carsten has begun in https://github.com/cbor-wg/edn-literal/pull/65 that feels like enough change to me that the doc might need to be returned to the working group.  I think we may have enough energy at the moment that we can get through this round relatively quickly, as long as we don't find any show-stoppers.

I apologize again for having come into the discussion later than would have been optimal.

As you said, waiting for Pete and Carsten (and others) to chime in; I value their opinions.

— 
Joe Hildebrand

> On Aug 26, 2024, at 8:31 AM, Orie Steele <[e-mail]> wrote:
> 
> Hi,
> 
> I'm following these discussions. 
> 
> If quality / stability / completeness are the concern, the working group can decide that EDN needs more work without changing its intended status.
> 
> The working group should consider the impact to readers and implementers and prioritize their needs over those of document authors / spec contributors.
> 
> My personal experience is as a document author working with EDN, and has been that its design seems to be driven primarily by Carsten's second point (I agree with both his points).
> 
> It's the deployment of EDN in software that should be guiding the decision to consider a proposed standard.
> If we're starting to feel growing pains or concerns regarding EDN's extensibility or security, I agree that is a good sign.
> 
> From a process standpoint, draft-ietf-cbor-edn-literals is in AD follow up. 
> The primary issue I am tracking is regarding the ABNF discussions, which are related to the question of extensibility, and the experience of implementers.
> 
> I would encourage the working group to come to consensus on a path forward for the document, are we addressing this last bit of ABNF-positioning and progressing the document?
> 
> Lets wait to hear from Pete and Carsten, the output of their collaboration could produce guidance that helps the working group decide on the broader context of the document.
> 
> If the design team's recommendations are inconclusive and/or the working group still wants to tackle some of these concerns with EDN with a larger update / change in document intended status,
> Then I would prefer to return the document to the working group, since there is a desire to do more work than just adjusting how to communicate ABNF.
> 
> I trust our chairs to make that determination, I encourage folks to reach out to the chairs privately if you do not feel comfortable commenting on the public list or at the mic line.
> 
> Regards,
> 
> OS, ART AD
> 
> 
> On Sun, Aug 25, 2024 at 12:11 PM Joe Hildebrand <[e-mail]> wrote:
> I would be ok with draft-ietf-cbor-edn-literals being standards track.  Config files are enough like big-I interchange in my opinion.  I've had to use too many informational drafts that got more implementation than anyone expected but were half-finished.  EDN feels like it would fit in that class if left informational.
> 
> That's a good thing if I'm right; it means that this doc might be broadly useful, which doesn't happen to all docs. :)
> 
> If we go this route, it means we're going to have to polish the doc until it glows.  Now that we've started, its' worth the effort, in my opinion.  That means thinking a lot more about interoperability and security, and nailing down our extensibility approach.  It also means that we probably need to add a section on exactly how it updates parts of other documents.
> 
> If there is an AD listening (or a chair would loop them, please), I'm interested in hearing opinions from the IESG early about how this approach would affect docs that use EDN for examples in the time it will take us to finish this work, and whether they have any advice for us.
> 
> — 
> Joe Hildebrand
> 
> > On Aug 25, 2024, at 10:40 AM, Carsten Bormann <[e-mail]> wrote:
> > 
> > On 2024-08-24, at 20:17, Joe Hildebrand <[e-mail]> wrote:
> >> 
> >> - I think this obsoletes Appendix G of 8610 now, which means 8610 should probably be in the updates list.  Similarly with section 8 of 8949.
> > 
> > In isolation, this does make sense to me (I don’t think we can’t obsolete sections; instead we update the documents containing them).
> > 
> > So far, the EDN draft was processed with a target of “Informational”; Appendix G of 8610 is explicitly marked as normative, and Section 8 of 8949 is not marked (and thus retains the normative context of the Internet Standard).
> > 
> > So there is this little can of worms whether the EDN document also should be marked as standards-track.
> > 
> > We have this gray area:
> > 
> > * One usage of EDN is for tools and configuration, which is its own kind of interchange, but not really the big-I Interchange that we normally reserve standards-track documents for.
> > 
> > * The other usage of EDN is within examples in normative RFCs, which often rely on the examples to make certain normative points, so an informational document would immediately need to go into downref (which is what we planned so far to handle this gray area, but might want to revisit).
> > 
> > I don’t have a strong opinion on any of this, but I wouldn’t want the WG to create a configuration of these choices (informative/standards-track, updates or not) that gets stuck in the IESG or makes documents using EDN get stuck in the IESG.
> > 
> > Grüße, Carsten
> > 
> > _______________________________________________
> > CBOR mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> 
> _______________________________________________
> CBOR mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 
> 
> -- 
> 
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>