On Wed, Aug 7, 2019 at 4:57 PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
Richard,
On 08-Aug-19 06:38, Richard Barnes wrote:
>
>
> On Wed, Aug 7, 2019 at 1:50 PM Eric Rescorla <ekr@xxxxxxxx <mailto:ekr@xxxxxxxx>> wrote:
>
>
>
> On Wed, Aug 7, 2019 at 8:30 AM Robert Sparks <rjsparks@xxxxxxxxxxx <mailto:rjsparks@xxxxxxxxxxx>> wrote:
>
>
> On 8/7/19 9:52 AM, Benjamin Kaduk wrote:
> > On Wed, Aug 07, 2019 at 06:13:08AM -0700, Eric Rescorla wrote:
> >> Dear IESG: can you report on the status of that project and when the
> >> tools/datatracker sites will show inline errata?
> > My understanding is that the code is done and waiting to be deployed.
> >
> > Alissa's note at
> > https://mailarchive.ietf.org/arch/msg/ietf/QDuj5ItTcY5nbVQVp7FMRjZiSZY may
> > be the most authoritative thing I can point to right now.
>
> This is currently in the rfc-editor's hands (as their plan is to deploy
> it on the rfc-editor website).
>
>
> I certainly agree it would be good to deploy it on the rfc-editor web site, but lots of people go to datatracker and tools, so that shouldn't hold up deploying it on the IETF sites.
>
>
> Deploying it on rfc-editor.org <http://rfc-editor.org> seems fine, but of very little value compared to datatracker and tools.
Since you've mentioned the elephant in the room...
> Google, for example, seems to stick to the following ranking when you search "RFC XXXX":
>
> 1. tools.ietf.org <http://tools.ietf.org>
> 2. datatracker.ietf.org <http://datatracker.ietf.org>
> 3. rfc-editor.org <http://rfc-editor.org>
>
> (And indeed, sometimes puts other RFCs before rfc-editor.org <http://rfc-editor.org>, e.g.., https://www.google.com/search?q=rfc+5280)
I don't think that the current de fact SEO of one search engine should determine our policy. Also, if the user comes in via the DOI, they are sent to rfc-editor.org.
Wouldn't it be lovely if we had some metrics from these pages so we could know which ones actually get used?
> As an added benefit, datatracker and tools are controlled by the IESG, so the changes can be deployed there without needing to trouble the RFC editor.
But the errata mechanism is controlled by the RFC Editor, and applies to all streams. So it's natural that errata display in this new (and very welcome) form should originate at the RFC Editor site. I'd certainly be delighted to see the tracker and tools sites picking it up, but they are secondary sites as far as RFCs go, by definition.
Just because the RFC Editor holds the data doesn't mean that other people shouldn't display them differently. Indeed, datatracker and tools *already* display RFCs differently from the RFC Editor site. Adding in errata would just be a further tweak in how the underlying data are displayed.
--Richard
As far as I can see, things are currently quite well integrated - if you click on the 'HTML' button in the RFC Editor's landing page for an RFC, you get a mirror of the tools site htmlized version. Presumably with the new format it will be the converse - the htmlized version will originate at the RFC Editor site.
(How the search engines will manage with the new format is also an interesting question.)
Brian
