I think we should just stick with "header" consisting of one or more
"header fields" where each "field" can span one or more "lines".
There's been some effort to maintain that consistency of terminology in
the past (to the extent that drafts often got feedback of the form "you're
not using the words in the standard way", and were often changed to
reflect the above terminology).
And yes, a few RFCs have fallen through the cracks and failed to adhere
to the standard terminology. But we'd have the same problem if we moved
to different terminology. I really can't see the justification for
doing so as long as the existing terminology suffices to describe these
protocol elements. Choosing new terms won't do anything to prevent
misuse of those new terms. And choosing new meanings for old terms
will only create more confusion.
And we should also just accept that "header fields" are going to be
abbreviated to "headers" once in awhile, and we're going to have to
sort out the differences by context. (At least in English and in
several other languages, such disambiguation is quite normal and we
don't even think about it as long as we can get the right meaning
most of the time.)
Keith