On 9/12/18 3:51 PM, Stephen Farrell wrote:
Hiya,
On 12/09/18 19:10, Adam Roach wrote:
Thanks for weighing in, Bob. I have a request for clarification.
On 9/11/18 1:31 PM, Bob Hinden wrote:
I worry about the
"abstract should contain enough detail to help readers decide if
they need to read the rest of the RFC"
This may result in a long Abstract depending on the nature of the
"update" and defeat the purpose of the abstract if it gets too long.
Based on other people's comments, you're not alone in such a concern,
and I'd like help understanding why. My conception of document abstracts
in general is that they serve the singular purpose of letting people
know whether they should read the rest of the document. This makes the
text you quote almost tautological.
Clearly, you (and others) have a different notion of the purpose of the
abstract section, and that understanding is driving these concerns. I
don't think we can reach a reasonable consensus unless we surface what
those differences in understanding are.
Can you concisely describe what purpose you believe an abstract serves?
There are more than just functional properties. There's the issue of
folks having to jump through bureaucratic hoops. For some documents,
it'll be just fine if this information is somewhere other than the
abstract.
I still don't follow. If the abstract does not contain enough
information to let someone know whether they want to read the rest of
the RFC, then what purpose *does* it serve? I note that many (non-IETF)
protocol specifications are published without an abstract at all. If
ours doesn't serve any purpose, then perhaps it's time we discussed
whether RFCs need them at all [1].
/a
____
[1] To be clear, I think this would be a Really Bad Idea, but it's the
only logical conclusion I can draw from push-back on a proposal that our
abstracts do the one thing that abstracts are intended to do.
