Subject: [Tools-discuss] producing links to datatracker rather than tools version of docs

From: Dave CROCKER <[email-masked]>
Date: Mon, 29 Aug 2011 09:04:37 -0700

Folks,

The datatracker is now sufficiently mature and that it offers significantly 
better functionality to warrant efforts to make it be the preferred source for 
IETF published documents.

This means that a search for an I-D or an RFC should produce a datatracker link 
rather than, for example, a tools reference.  Currently, a google for a document 
always produces tools references at higher ranking and often produces no 
datatracker reference in the initial set.

Another change should be to have IETF announcements of RFCs and Internet Drafts 
produce a datatracker-based URL.

To be clear about the benefits:  The datatracker provides extremely important 
context for documents, such as History, IESG record and Errata.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Fred Baker <[email-masked]>
Date: Mon, 29 Aug 2011 09:38:57 -0700

On Aug 29, 2011, at 9:04 AM, Dave CROCKER wrote:

> Folks,
> 
> The datatracker is now sufficiently mature and that it offers significantly better functionality to warrant efforts to make it be the preferred source for IETF published documents.
> 
> This means that a search for an I-D or an RFC should produce a datatracker link rather than, for example, a tools reference.  Currently, a google for a document always produces tools references at higher ranking and often produces no datatracker reference in the initial set.
> 
> Another change should be to have IETF announcements of RFCs and Internet Drafts produce a datatracker-based URL.
> 
> To be clear about the benefits:  The datatracker provides extremely important context for documents, such as History, IESG record and Errata.

I disagree. Right now, my personal tool gives both links - for example:

http://datatracker.ietf.org/doc/draft-vanrein-v6ops-6bed4
http://tools.ietf.org/html/draft-vanrein-v6ops-6bed4
  "IPv6 Tunneling for Embedded Systems (6bed4)", Rick van Rein, 25-Jul-11

The datatracker tells me about IESG history, but it doesn't tell me working group history apart from current WG state, and it doesn't give me diffs - which the tools link does. At this point, I'm using both and find neither one predominant.

For RFCs, I have a number of options:
      http://www.google.com/search?q=rfc6296 gets me a list of pointers

From that,
      http://www.rfc-editor.org/info/rfc6296 gets me an overview and the text
      http://tools.ietf.org/html/rfc6296 gets me a link to the ID and text

What I don't see being accessed, at least as reported by Google, are
      http://datatracker.ietf.org/doc/rfc6296/?include_text=1
      http://www.ietf.org/rfc/rfc6296.txt
or    http://www.rfc-editor.org/in-notes/rfc6296.txt

> _______________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 29 Aug 2011 09:49:41 -0700

On 8/29/2011 9:38 AM, Fred Baker wrote:
> http://tools.ietf.org/html/draft-vanrein-v6ops-6bed4 "IPv6 Tunneling for
> Embedded Systems (6bed4)", Rick van Rein, 25-Jul-11

I'm sure folks' personal tools do all sorts of useful things.  I am commenting 
on public search tools and gave google as the example.  I also commented on on 
the formal announcements we make that include links.

> The datatracker tells me about IESG history, but it doesn't tell me working
> group history apart from current WG state, and it doesn't give me diffs -
 > which the tools link does. At this point, I'm using both and find neither one
 > predominant.

It does give a diff.  Under the history tab for a draft, the first section on 
the page is for getting a diff.  It defaults to the current compared with 
immediately preceding, but is easily set to different versions.  (The tools 
capability is fixed to only give current compared with immediately preceding.)

If you feel that the design of the datatracker is suboptimal, that's worth 
pursuing separately.

I had thought that the money spent on the datatracker was to produce a 
production capability and that the tools one was the prototype.  Is this not 
correct?

> For RFCs, I have a number of options: http://www.google.com/search?q=rfc6296
> gets me a list of pointers

None of the choices produced for me inlcude the datatracker.

In general I would expect that one of the expectations for spending money to 
develop the datatracker ought to be our making it preferred and easily found, 
rather than requiring folk to already know to use it.

d/
-- 

   Dave Crocker

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Aug 2011 11:05:32 -0700

+1

It was useful to determine a canonical URL for RFCs; given the ephemeral 
nature of IDs, I'm not sure it's as important.

However, if we want to change the content of an ID URL response we 
should change the response, not provide a different URL.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 29 Aug 2011 14:14:22 -0400

On Aug 29, 2011, at 12:49 PM, Dave CROCKER wrote:

> I'm sure folks' personal tools do all sorts of useful things.  I am commenting on public search tools and gave google as the example.  I also commented on on the formal announcements we make that include links.

I agree that the formal announcements should probably point to the IETF-hosted Datatracker. Having said that...

> It does give a diff.  Under the history tab for a draft, the first section on the page is for getting a diff.  It defaults to the current compared with immediately preceding, but is easily set to different versions.  (The tools capability is fixed to only give current compared with immediately preceding.)
> 
> If you feel that the design of the datatracker is suboptimal, that's worth pursuing separately.

It might be better to wait on making the change to point to the Datatracker until the Datatracker has a stable set of functionality. For example, many people have complained that the default view of the Datatracker for drafts is an abbreviated version that has to be expanded. Others have complained about the diff being hidden behind two clicks. Others have complained about ... .

There has not been a concerted effort to get a general consensus on the main Datatracker functionality for drafts and RFCs. If such an effort takes place, there is a 100% chance that the web UI will change.

> I had thought that the money spent on the datatracker was to produce a production capability and that the tools one was the prototype.  Is this not correct?

The first assertion is true but not sufficient for your request. The second is not true. The Tools tool has different levels of deployment status, but I don't think any is considered a prototype for the Datatracker.

> None of the choices produced for me inlcude the datatracker.

The RFC Editor might, in fact, prefer that rfc-editor.org appear before the Datatracker. This is a serious consideration before the IETF asks "one of our contacts" at Google to change the preferred search results for RFCs.

> In general I would expect that one of the expectations for spending money to develop the datatracker ought to be our making it preferred and easily found, rather than requiring folk to already know to use it.

+1

--Paul Hoffman

---

From: Richard Barnes <[email-masked]>
Date: Mon, 29 Aug 2011 14:47:12 -0400

ISTM that the tools system already provides a stable URL for I-Ds,
although maybe as a consequence rather than an intended feature.
After-all, if you leave the version number off of a draft, you always
get the newest version, e.g.:
<http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol>

I've actually found that particular feature useful on several occasions.

--Richard

On Mon, Aug 29, 2011 at 2:05 PM, Joe Touch <[email-masked]> wrote:
> However, if we want to change the content of an ID URL response we should
> change the response, not provide a different URL.
>
> Joe
>
>
>>> The datatracker is now sufficiently mature and that it offers
>>> significantly better functionality to warrant efforts to make it be the
>>> preferred source for IETF published documents.
>>>
>>> This means that a search for an I-D or an RFC should produce a
>>> datatracker link rather than, for example, a tools reference.  Currently, a
>>> google for a document always produces tools references at higher ranking and
>>> often produces no datatracker reference in the initial set.
>>>
>>> To be clear about the benefits:  The datatracker provides extremely
>>> important context for documents, such as History, IESG record and Errata.
>>
>> The datatracker tells me about IESG history, but it doesn't tell me
>> working group history apart from current WG state, and it doesn't give me
>> diffs - which the tools link does. At this point, I'm using both and find
>> neither one predominant.
>>

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 29 Aug 2011 11:56:15 -0700

On 8/29/2011 11:14 AM, Paul Hoffman wrote:
> many people have complained that the default view of the Datatracker for drafts is an abbreviated version that has to be expanded. Others have complained about the diff being hidden behind two clicks. Others have complained about ... .

Where are these complaints being lodged?

> There has not been a concerted effort to get a general consensus on the main Datatracker functionality for drafts and RFCs.

I thought that that was what you had been paid to develop.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 29 Aug 2011 12:05:07 -0700

Folks,

A number of the comments seem to be missing the underlying point I'm trying to 
make:

    We need to help folks who don't know the tricks.

The two most significant way to help folks are through public search engine 
listings and through the formal notices.

These should highlight the best entry we have available.  We've just sent a heap 
of money on the datatracker and, indeed, it looks quite good.  Let's help folks 
find it.

d/
-- 

   Dave Crocker

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Aug 2011 21:08:10 +0200

On 2011-08-29 20:14, Paul Hoffman wrote:
> ...
> ...

Unless I'm missing something, that's not how things work.

If we want a particular URI to rank high, we need to play by the rules: 
establish link relations, and make sure that sites with a high rank 
(wikipedia, for instance) actually link to the version we prefer.

Best regards, Julian

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 29 Aug 2011 21:12:07 +0200

On 29 August 2011 18:38, Fred Baker wrote:

>> The datatracker provides extremely important context for documents,
>> such as History, IESG record and Errata.

>  "IPv6 Tunneling for Embedded Systems (6bed4)", Rick van Rein, 25-Jul-11

+1, and the RECOMMENDED (by me, not "officially") tools.ietf.org pages
offer links to the tracker and the errata.  In fact my personal tool
(Google custom search) eliminates all links to other I-D and RFC repos,
because they don't do what I want.

Sadly some IETF mailing lists still list only "unusable" URLs instead
of simply adding the "working" tools.ietf.org URL.

-Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 29 Aug 2011 21:22:37 +0200

> (wikipedia, for instance) actually link to the version we prefer.

Check out <URL:http://en.wikipedia.org/wiki/MediaWiki_talk:Rfcurl> for
the history of the current MediaWiki default.  It's possible to define
another rfcurl system message per MediaWiki project, but I'd scream if
admins actually try that on any MediaWiki installations I care about.

-Frank

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Aug 2011 12:37:13 -0700

On 8/29/2011 12:08 PM, Julian Reschke wrote:
>> The RFC Editor might, in fact, prefer that rfc-editor.org appear
>> before the Datatracker. This is a serious consideration before the
>> IETF asks "one of our contacts" at Google to change the preferred
>> search results for RFCs.
>> ...
>

Or make sure most of them point to the same place ;-)

Joe

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Aug 2011 21:39:37 +0200

On 2011-08-29 21:22, Frank Ellermann wrote:
> Check out<URL:http://en.wikipedia.org/wiki/MediaWiki_talk:Rfcurl>  for

Yep.

I'm also not convinced that it's actually a good idea to make something 
that is currently being generated on the fly (it is, right), the default.

I know that Henrik put a lot of work into the tools.ietf.org scripts to 
that everything that can be static *is* static, and that things scale 
well...

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 29 Aug 2011 15:48:15 -0400

> that everything that can be static *is* static, and that things scale

fwiw, i'm quite happy with the tools pages.  They're very clean,
well-indexed, and provide stable URLs for per-page and per-section
reference.  They're also not distracting at all if you want to just
focus on the RFC as-published.

I understand that the datatracker has much more functionality available,
though.  Perhaps we could just convince Henrik to add an outbound link
from the tools page to the relevant (stable) datatracker page?

Many thanks to everyone who has worked on both tools and the
datatracker.  These are excellent resources.

Regards,

	--dkg

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Aug 2011 10:11:26 +1200

+1 to Fred. IMHO we need both types of link, because they serve different purposes.

   Brian