[art] [IANA #1270376] IANA section with long lines

[Amanda Baber via RT <[e-mail]>]

Hi Robert, 

I see Carsten mentioned that the RFC Editor turns tables into a definition list, but we complete the registry actions when the IESG approves the document, at the same time that the RFC Editor is notified that it's been approved. We aren't working from their text. Is it possible to leave that large table in place until the document is approved?

thanks,
Amanda 

On Thu Apr 06 11:23:50 2023, [e-mail] wrote:
> Hi Amanda,
> 
> the table in https://www.ietf.org/archive/id/draft-ietf-calext-
> jscontact-09.html#name-initial-contents-for-the-js is of the same
> format and is considerably longer. I do not see how we could split
> this table into two tables without losing context for the reader.
> 
> We can convert this to a list of <dl> elements as Carsten Bormann has
> suggested.
> 
> Will that work for you?
> 
> Thanks,
> Robert
> 
> On Thu, Apr 6, 2023, at 1:18 PM, Amanda Baber via RT wrote:
> > Hi Daniel,
> >
> > If this were a really large table, I would ask if it could remain in
> > place until the IESG approves the document, which would let us copy a
> > tab-separated table from the HTMLized version and run a little script
> > to convert it into XML records. However, because there are only a
> > couple of entries there, I would suggest either 1) breaking it up
> > into two tables (four fields in each?) or 2) reducing the table to
> > the  first four fields and noting in the paragraph above it that for
> > both entries, the intended usage is "common," the since version is
> > "1.0," the change controller is the IETF, and the until version field
> > should be left blank.
> >
> > thanks,
> > Amanda
> >
> > On Wed Apr 05 19:34:01 2023, [e-mail] wrote:
> > > Hi,
> > >
> > > We do have an editorial question. The current version of
> > > draft-ietf-calext-jscontact-vcard-07.txt [1] has 17 lines that
> > > exceeds
> > > the
> > > 72 character limit in the IANA section (5.3.  New JSContact
> > > Properties).
> > >
> > > We would like to understand if there is anything we should do and
> > > if
> > > so,
> > > what is the most convenient way to handle this for the IANA.
> > >
> > > Yours,
> > > Daniel
> > >
> > > [1] https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-
> > > vcard-
> > > 07.txt
> > >
> > > On Wed, Apr 5, 2023 at 12:11 PM Daniel Migault
> > > <[e-mail]>
> > > wrote:
> > >
> > > > My suggestion is that we move forward with the publication while
> > > > checking
> > > > with the IANA and the RFC Editor how to best handle this if that
> > > > causes an
> > > > issue.
> > > > Yours,
> > > > Daniel
> > > >
> > > >
> > > > On Wed, Apr 5, 2023 at 8:11 AM Robert Stepanek
> > > > <[e-mail]>
> > > > wrote:
> > > >
> > > >> We just published new versions for the RFC
> > > >> documents draft-ietf-calext-jscontact, draft-ietf-calext-
> > > >> jscontact-
> > > >> vcard
> > > >> and draft-ietf-calext-vcard-jscontact-extensions:
> > > >> https://datatracker.ietf.org/wg/calext/documents/
> > > >>
> > > >> These versions address all but one Last Call feedback item we
> > > >> got.
> > > >> Francesca, Bron, Daniel, could you please let us know how to
> > > >> proceed
> > > >> on
> > > >> this one remaining item? Please see below.
> > > >>
> > > >> On Wed, Mar 29, 2023, at 8:02 PM, Paul Kyzivat wrote:
> > > >>
> > > >> Document: draft-ietf-calext-jscontact-vcard-06
> > > >> Reviewer: Paul Kyzivat
> > > >> Review Date: 2023-03-29
> > > >> IETF LC End Date: 2023-04-07
> > > >> IESG Telechat date: ?
> > > >>
> > > >> 7) NIT:
> > > >>
> > > >> IdNits reports the following of significance:
> > > >>
> > > >> [..]
> > > >>
> > > >> ** There are 30 instances of too long lines in the document, the
> > > >> longest
> > > >> one being 18 characters in excess of 72.
> > > >>
> > > >>
> > > >> We now shortened long lines in all examples and art work. The
> > > >> remaining
> > > >> long line warnings are due the plain text rendering of the table
> > > >> layout
> > > >> that we chose in the IANA considerations section. We have no
> > > >> control
> > > >> over
> > > >> how these are rendered and would need to change to a list-based
> > > >> or
> > > >> other
> > > >> layout for more control about line lengths.
> > > >>
> > > >> Before we spend effort on doing that, we would first like to
> > > >> understand
> > > >> what's best for IANA to process these documents? Is the current
> > > >> table
> > > >> layout for registries preferred, just as we did for RFC 8984
> > > >> (JSCalendar)?
> > > >> For IETF, do the long lines in prevent us from proceeding with
> > > >> publication?
> > > >>
> > > >> Thanks,
> > > >> Robert
> > > >>
> > > >
> > > >
> > > > --
> > > > Daniel Migault
> > > > Ericsson
> > > >
> >
> >