@mtdowling: As I wrote, I suspect what you mean is a `MessageHeaderFieldsInterface` and not `HeaderValuesInterface`. The term `HeaderValues` for what you state is wrong and breaking the nomenclature of RFC 2616.

To make this even more distinct, with all respect, let me pick your paragraph apart to just underline the differentiation I thin is important here.

> There can be multiple header values for any given header.

No there can't. There can be multiple message-header-fields with the same name, but not multiple header-values with the same header-name in a HTTP message. Read the specs carefully, there is a difference made between "header-name : header-value" pairs and message-header-fields.

This is a fine difference that should be preserved in the wording of the interface.

>  Whether or not they are represented on multiple lines in the HTTP message headers or concatenated using a comma is not addressed in this PSR and I don't think it should be.

I think it is fine if the PSR would not address this - but the PSR addresses this by tainting the wording of header-value per the wrong named interface. So what I'm basically suggesting right now is exactly changing the wording of the interface and to not group (or concatenate) multiple message-header-fields by their name but just provide ordered access.

> Anyone can add any header, and this PSR making decisions about which headers go on multiple lines vs concatenated with a comma is untenable.

Yes, that is certainly right. I would say, that the same that applies for concatenating applies for grouping as well. This PSR should not make decisions to group message-header-fields by their field-name.

I would also favor if the wording is not just "header" but that there is a distinction between a message-header-field or the "field-name : field-value" pair. Doing that differentiation should add more clarity.

> Also, what are "concrete field values"?

I see those as concrete field values in any "field-name : field-value" pair, of there is one per name in a HTTP message (in transport this can be over multiple message-header-fields with the same field-name - but that is transport and not a concrete value. I hope this makes it more clear).

> Also, I'm open to changing the name if that would make things more clear.

Yes, I think this solves most of the issue. This additional leaves room to also offer some more abstract access to values, albeit if there is a clean interface for message-header-fields, I don't know if an interface for concrete header values is still necessary as this is an implementation detail and as concatenation should not be part, grouping shouldn't be part as well. Perhaps a filtered-by-name list of message-header-fields could be offered by that interface and the list of used field-names next to providing an iterator over all message-header-fields.