Re: [rfc-i] t with indent

On Tue, Dec 29, 2020 at 1:35 PM John R Levine <johnl@taugh.com> wrote:

> On Tue, 29 Dec 2020, Eric Rescorla wrote:
> >> If someone can find consistent semantics in the thousand fake indents
> >> I wouldn't be opposed to adding semantic tags (even retroactively) but
> >> I'm not holding my breath.
> >
> > Well, I certainly don't think all of them will have the same semantics.
> > Rather,
> > what I would expect is that the majority fall into a relatively small
> number
> > of buckets. We'd then need to go and look to see whether it was worth
> > having a typographical feature like this for the remainder or whether
> > we could just live with suboptimal typesetting in those cases -- it's not
> > like it would be the first time our typesetting was suboptimal!
>
> Sounds like a good project for someone, but I'm not volunteering at this
> point.
>

Do we have a list of the cases where this has happened? If so, I'd be
willing to sample and do a survey.

-Ekr

>> The default is zero so I agree that there's no need to indicate zero
> >> indents.
> >>
> >
> > That seems like a good start. What's the process for doing that? Based on
> > Julian's note it sounds like this is a requirement documented somewhere.
>
> It's in RFC 7998:
>
> 5.2.  Defaults
>
>     These steps will ensure that all default values have been filled in
>     to the XML, in case the defaults change at a later date.  Steps in
>     this section will not overwrite existing values in the input file.
>
> In retrospect, we should have flipped it around and said that the XML
> default values aren't going to change.  There's a lot of stuff in RFCs
> 7991 to 7998 that has turned out to be a poor match for practice.
>
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>