Subject: getting w3c to point to current RFCs

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Sep 2017 10:07:03 -0400

While googling for the syntax for Content-Type (if there are multiple
paramaters how are they seperated? The answer is ;), I came up with:
  https://www.w3.org/Protocols/rfc1341/4_Content-Type.html

as a top-hit.  I guess it's an expansion of rfc1341 by the URL.
But there are no navigation links on the page, and truncating to
/Protocols/rfc1341 didn't give me anything.
And, well, it's a really really old obsoleted RFC.
(with a slightly different ABNF to newer documents. I didn't immediately
notice/understand the *[] part around parameter, although it's obvious in hindsight)

In particular, it doesn't easily lead the reader to find the original RFC1341
in anyway, and perhaps it actually violates the IETF copyright.  I don't so
much care (personally...) if the copyright is violated, more I care that the
RFC-editor obsoleted-by information is not clear to the reader and no obvious
way from that page to find the original document.

Can we get w3c to something different here?
I think that we now have anchors links to sections of RFCs, although perhaps
not on the rfc-editor.org copy as yet. (cf: flame war in tools-discuss which I kill-filled)

I eventually found the definition via RFC5822, referencing to RFC4021,
and hence to RFC2045 section 5.1.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Julian Reschke <[email-masked]>
Date: Thu, 14 Sep 2017 07:52:43 +0200

> Can we get w3c to something different here?

We asked when obsoleting 2616 (for which there are lots of links to the 
W3 "version")... I believe the issue is that they neither want to remove 
nor modify their copies. (cc'ing Yves).

> ...

FWIW, if you're looking for the syntax of Content-Type as HTTP header 
field, the right answer would be RFC 7231.

To find the *registered* definition of any MIME/HTTP header field, see 
<https://www.iana.org/assignments/message-headers/message-headers.xhtml>.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Sep 2017 15:53:09 +1000

Hi MIchael,

That's part of <https://www.w3.org/Protocols/>, which AIUI the W3C sees as a historical view of Web protocols.

I'm not a lawyer, but I would be surprised and concerned if we started going after sites that had copies of RFCs posted on them for copyright; at any rate, the IETF Trust is never the sole owner of copyright in specifications AIUI, so proving that we had the right to do so would take more work.

Perhaps the real problem here is that the versions of RFCs that we host don't get very much attention from search engines. While this is no doubt in part because people don't link to them (in my experience, people will always link to a "prettier" version if available), it also may be because we don't help ourselves; e.g., in my search engine of choice:

Cheers,

> On 14 Sep 2017, at 12:07 am, Michael Richardson <[email-masked]> wrote:
> 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 14 Sep 2017 09:00:51 +0200

On 2017-09-14 07:53, Mark Nottingham wrote:
> I'm not a lawyer, but I would be surprised and concerned if we started 
> going after sites that had copies of RFCs posted on them for copyright; 
> at any rate, the IETF Trust is never the sole owner of copyright in 
> specifications AIUI, so proving that we had the right to do so would 
> take more work.
> 
> Perhaps the real problem here is that the versions of RFCs that we host 
> don't get very much attention from search engines. While this is no 
> doubt in part because people don't link to them (in my experience, 

Having "proper" HTML should help (in the not so distant future).

> people will always link to a "prettier" version if available), it also 
> may be because we don't help ourselves; e.g., in my search engine of choice:
> ...

Well - that's an interesting problem that I'm pretty sure we^^Henrik can 
fix. Does anybody understand *what* the search engine is complaining about?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Sep 2017 17:03:19 +1000

Probably this:
  https://tools.ietf.org/robots.txt

> On 14 Sep 2017, at 5:00 pm, Julian Reschke <[email-masked]> wrote:
> 
>> Perhaps the real problem here is that the versions of RFCs that we host don't get very much attention from search engines. While this is no doubt in part because people don't link to them (in my experience, 
> 
>> people will always link to a "prettier" version if available), it also may be because we don't help ourselves; e.g., in my search engine of choice:
>> ...
> 
> Well - that's an interesting problem that I'm pretty sure we^^Henrik can fix. Does anybody understand *what* the search engine is complaining about?
> 
> Best regards, Julian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Sep 2017 09:36:18 -0400

Mark Nottingham <[email-masked]> wrote:
    > That's part of <https://www.w3.org/Protocols/>, which AIUI the W3C sees
    > as a
    > historical view of Web protocols.

Yeah, I don't have a problem with it, I just don't like that it does not
identify where the document is from, who wrote it, or how to find newer
versions.

So, could we ask the w3c to simply link back to the original documents in
these pretty pages?  That's all I want.

    > doubt in part

I also agree with you here.

---

From: John C Klensin <[email-masked]>
Date: Thu, 14 Sep 2017 10:58:22 -0400

--On Thursday, September 14, 2017 15:53 +1000 Mark Nottingham
<[email-masked]> wrote:

>...
> I'm not a lawyer, but I would be surprised and concerned if we
> started going after sites that had copies of RFCs posted on
> them for copyright; at any rate, the IETF Trust is never the
> sole owner of copyright in specifications AIUI, so proving
> that we had the right to do so would take more work.

There is also a tradition, going back to when RFCs had
single-digit numbers, that copying, distribution, and reposting
of complete RFCs is always allowed.  That was expressed in every
RFC for many years with the phrase "Distribution of this memo is
unlimited".   Newer boilerplate refer to BCP 78 and the Trust
Legal Provisions, the latter of which contain (version 5.0,
Section 3(c)(i)) unlimited permission to "copy, publish, display
and distribute IETF Contributions and IETF Documents in full and
without modification" [1].   So, any attempt to "go after" such
sites would violate our rules.

> Perhaps the real problem here is that the versions of RFCs
> that we host don't get very much attention from search
> engines. While this is no doubt in part because people don't
> link to them (in my experience, people will always link to a
> "prettier" version if available), it also may be because we
> don't help ourselves; e.g., in my search engine of choice:

I don't know about that piece of the problem, but we also don't
help ourselves by creating confusion about whether the copy of
an RFC that is referenced should be the one on the RFC Editor
site or the tools site.  Moving toward multiple authoritative
versions isn't going to help with that either (your comment
about "pretty" versions notwithstanding, views about what is
pretty are not consistent and, e.g., some of us prefer copies
that are easy to grep).   If six people reference a given RFC,
one references the RFC Editor ASCII copy, one their PDF copy,
one references a copy on the Upper Slobbivian mirror site, and
one each references the ASCII, PDF, and HTML versions on the
Tools site, search engines that don't have special knowledge are
going to see six links, dividing what they believe is the number
of references to that document by six.

This is precisely the argument for actual persistent identifiers
or content (and maybe even format-independent content) rather
than pathnames or URLs that depend on locations.  But we can't
agree to reference RFCs using URNs, DOIs, or something
equivalent and people who use references of those types just
further reduce the link frequency counts for any particular way
of referencing the the RFC.

If people think the above is a problem that needs solving, I see
much of it as being within the scope of the IESG and RFC Editor
to fix by publishing the preferred link form in each RFC (and on
the tools pages, etc.) rather than leaving it up to the user's
imagination.  If they aren't interested and one still thinks it
is important, tell the IAB to think about it, possibly by
putting it on the agenda of the forthcoming identifier workshop
and/or making willingness and ability to deal with it forcefully
on the requirements list for the RFC Series Editor contract.
And, if none of that works, tell it to the Nomcom.

Whether any of that will change W3C's behavior is another
question, I think your "we don't help ourselves" comment is
important.

   best,
     john

[1] Whether it is wise to bury the redistribution provision that
deep in fairly complex and legalistic documents, or to handle on
a basis that the Trust, could in principle, change on a whim, is
another matter.  I note, in that context, that the "Legend
Instructions" of RFC 5378 (aka BCP 79) points to
http://trustee.ietf.org/license-info, but that link redirects to
the Trust Legal Provisions main page
(https://trustee.ietf.org/trust-legal-provisions.html ) which
not only does not contain the Legend information but doesn't
point clearly to where it is.  The problem goes downhill from
there; I've just filed an erratum on RFC 5378 to try to get a
stake in the ground about this.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Sep 2017 10:53:56 -0400

​I think part of the problem here could be solved if someone was willing to
put some work into some scripting... The basic information all exists. But
it is not currently exposed in a useful fashion.

My RFCTool (open source, MIT license) automatically translates normative
and informational references into citations. So to create a reference to
RFC822, I would write:

<norm="RFC822"/>

(Yes this is not XML, I am aware of that, this is markup for use inside
either Markdown or Word document source, I regard xml2rfc as being an
output format, not an editing format, I mostly support it for input so as
to create an editing format)

The tag above causes my tool to note the label starts with RFC and uses the
rest of the label to form a URL which is used to attempt to pull the
citation from the tools directory. Unlike the XML approach which requires
the reference to be stated in three places, I specify it in exactly one.

I don't think I want to change the way I cite numbered RFCs because I
sometimes use them to intentionally refer to something that was changed.
But we have discussed the idea of short names for RFCs on RFC-interest. We
already create such names when we use drafts. Why throw away the
information.

Let us say we had used SMTP and SMTP-Message as the short names for RFC-821
and RFC-822. We could then use <norm="RFC-SMTP-Message"/> to refer to the
latest version in the document and this could automatically pull up RFC5322
which is the latest version.

What it would take to make that happen is

1) Someone writes a tool to convert existing information into relevant
citation files
2) Someone goes through the back catalog that isn't tracked in the database.

One question is whether we actually archive the XML versions of RFCs
anywhere, I just had an look and could not see it but I might just have
picked RFCs written in nroff.

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Sep 2017 18:12:51 -0400

--On Friday, 15 September, 2017 10:53 -0400 Phillip Hallam-Baker
<[email-masked]> wrote:

>...
> Let us say we had used SMTP and SMTP-Message as the short
> names for RFC-821 and RFC-822. We could then use
> <norm="RFC-SMTP-Message"/> to refer to the latest version in
> the document and this could automatically pull up RFC5322

This works as long as "the latest version" is a replacement for
the older one on a substantive point by substantive point basis.
Carrying your example a bit further, while 5322 is probably such
a replacement for 822 and 2822 (or close to it), 5321 is _both_
a replacement for "RFC-SMTP" (821, 2821) and for what might be
called "RFC-SMTP-Extensions" (1425, 1651, 1869).   If one tries
to handle that by naive use of short names -- something designed
for a different purpose -- there is considerable risk of
creating more problems than it would solve.  

If we think the problem is to create stable references to an
abstraction of a document rather than to specific documents, we
could assign STD numbers to Proposed Standards (not exactly the
first time that has been suggested) or create summary statements
of what documents are about and reference them (not the first
time for that one either).  But let's not pretend there are
easy, magic bullets (via unsystematically-assigned short names
or otherwise)...there just aren't.

  best,
   john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Sep 2017 19:45:01 -0400

> or otherwise)...there just aren't.

​I had thought of that but hadn't really wanted to shave the yack quite as
much.

90% of the time, I find that my references are to the group of docs just
like you say. If I am talking about DNS, which document I reference is
fairly clear but sometimes there are five docs and it is a toss up.

Some of the vagaries are captured by 'updates' which produces 'updated by'.
But what we don't get is 'related to'.​