[rfc-i] comments on RFC style guide draft
Heather Flanagan (RFC Series Editor)
rse at rfc-editor.org
Thu Jan 23 08:14:41 PST 2014
On 1/23/14 7:45 AM, George, Wes wrote:
> On 1/22/14, 8:27 PM, "Heather Flanagan (RFC Series Editor)"
> <rse at rfc-editor.org> wrote:
>> I haven't been trying to sneak drafts in
>> behind the scenes. :-)
> No worries, saw it go past in the RSS feed, had a few cycles to read
> through. :-)
I appreciate that you took the time!
>>> As to the current text:
>>> The criteria for determining whether a page is a “personal web page” and
>>> therefore unacceptable as a citation must be clearly defined, or this
>>> restriction should be eliminated. The RSE is not equipped to determine
>>> which websites are stable and which are not based on a spot evaluation
>>> at the time of publishing, and it’ll just lead to unproductive arguments
>>> with authors if it’s “I’ll know it when I see it."
>> I understand your point, but I have to disagree about removing room for
>> interpretation by the editors. Judgement calls are a regular part of
>> what we do, and I want to find a balance between reasonable guidance and
>> rigid prescription during those judgement opportunities.
> I’m not suggesting making it so prescriptive as to remove all judgement
> from the editors. However, as an author, I need better clarity to guide my
> selections of references. I think you’re right about the balance, and
> perhaps the philosophy or rules of thumb guidance that you’d give your
> editors in making these judgement calls may just need to be documented
> somewhere so that an author (and WG) can ask themselves the same questions
> well before it hits your queue.
The editors and I talk about this regularly; this is one of the harder
things to put in anything like a publishable checklist.
To provide some examples, here are some things that would cause the
editors to question when they go check a link:
- the site includes pointers to personal cat photos, travelogues, or
other clearly personal things
- the document on the site was obviously scanned or copied from a
- the URL is in the pattern of http://www.institution.edu/~jsmith
There are more, but it largely comes down to a value judgement when we
actually look at a site. If you have any wording to suggest, Sandy and
I would appreciate how to tighten up the guidance for all concerned
(while, of course, leaving room for judgement calls).
>> Our current process, to accept
>> changes to contact information and adjust our information internally, is
>> not ideal, but I am at a loss for a better way for that meets the needs
>> of the IETF community.
> I didn’t realize that it was possible to update contact info, but that may
> be my fault. Is that published anywhere?
To be honest, I think this falls in to the realm of "lore people learn
through osmosis" or something. We have not aggressively published this,
since we're not really geared towards handling a flood of change
requests. That said, I see these requests come in every week, usually
from authors who are writing their n+1 RFC and have had their contact
information change since the last time they published.
>>> Alternatives that come to mind:
>>> -creating a permanent email alias such as RFCnnnn at tools.ietf.org
>>> <mailto:RFCnnnn at tools.ietf.org> that allows the authors to update the
>>> contact email address associated with them if and when it changes (this
>>> goes towards support of a metadata model for RFC format, I suppose).
>> I have several concerns about this approach - what about non-IETF
> I’m not sure I follow you. What RFCs does the RSE publish that are
> non-IETF documents?
The IRTF, IAB, and Independent Submission streams are not IETF
documents. They are in the minority, definitely, but they are there and
have slightly different rules regarding process, boilerplate, etc.
>> How does this solve for authors who, for whatever reason, do
>> not keep up with their contact information. Still, perhaps something
>> could be suggested as a code sprint project. More thought is needed here.
> It’s still dependent on the authors. However, to your point about code
> sprint: Recently, it came to light that there is some functionality built
> into the IETF mailing list management software that gives you a
> single-entry way to change all of your existing IETF list subscriptions to
> a new email address at once. Might not be that hard to add some
> capabilities to at least identify and prompt people to update RFC metadata
> based on a search for RFCs matching the old email address…
Will you be in London? This might be easier to hash out in person, and
I'd like Alice to be involved.
>>> -allowing an erratum to be filed against the RFC to update author
>>> contact info (this preserves the archival nature of the document, while
>>> allowing for an important update to ensure that the author can be
>>> contacted for IPR matters, questions/comments, etc).
>> I'm not clear on what you mean - allow the author to submit an errata
>> when their address changes, or allow a reader to submit an errata when
>> they cannot reach the author?
> I meant the former, but suggested that when I didn’t realize that you
> already had a manual update process, so it’s probably irrelevant.
Not entirely irrelevant, given the inefficiency of the current process.
But there are probably better ways than the errata system, at least
given how the errata system works today.
> Thanks for the responses!
More information about the rfc-interest