@mtdowling: I have to apologize as well. English is not my native language and I very much can understand the point you raise about opinions as it is sometimes really hard to discuss and wiggle things when the communication is in writing. So please read my comments and feedback lightly, I tried to make differentiation visible where I think it's worth to differentiate, however as we're programmers and having three opinions about each point each of us, this can become picking. That's not my intention and I can see that you're doing a lot of work here that needs to be honored. And you're actually pretty responsive to the feedback. And it's also good that you've got the background because of your work in Guzzle, thank you for that, I do see this generally as something positive. Without implementation experience this would lead nowhere. And I dunno how often I've read that RFC myself over the years and I still find details that didn't caught my attention yet. To summarize: I truly think that an abstraction of what a field-name : field-value pair is in HTTP is useful for a HTTP Message abstraction. The problem I have with it is that it is diffuse about the multiple-header-line cases. Because of that I would toss that problem away into an interface that deals with those. About the meaning of such a value being a string I'm also not that clear. At first sight string seems the natural choice, however, I'd say it's okay if the value is something that works in string context. E.g. it can be some value object representing an RFC date, so some DateTime-kind-subtype that has __toString() itself. To allow better designs (or perhaps better said: more flexible usage) on a consumer level, having a distinct getter here for the value can be helpful, and directly "burning" __toString() on the object representing the value (and not the [Value-Object](http://martinfowler.com/eaaCatalog/valueObject.html)) looks like a reduction, not an addition to me (even you add the __toString() method to the interface, it is not adding at the specs level, it's only defining of what you think is useful in practice, albeit nothing in PHP prevents you to add these at the implementation level. It's perhaps better per the draft to be less conservative here and embrace broader adoption by being not that definitive in the interface)

In the current draft, I do primarily see a problem (not saying I know the solution already) with returning multiple values for the same field (the array, or what I named grouping earlier). From the discussion so far, I tend to say that if the specs you create are handling this point well and the interface can more distinctively express what a field-value is, that the specs do greatly benefit.

As I can not solve something fundamentally contradicting (a string is not an array of strings), my suggestion so far is to have an interface that can represent well and simple the nature of a HTTP message header having the same field-names on multiple lines.

On the other hand I do see that for a consumer it is also of use to have an interface that directly represents a field-value accessible via a field-name. At that place I would do document some meanings like the normalization of field-names (case, trim etc.) whereas on the level of the message header lines that are to transport the information of such values (those starting with a field-name, those message-header-filelds (`MessageHeaderFieldsInterface`) can offer access on the lower level. I think this is actually already important if you want to deal with Cookies. Even those are related to HTTP, their usage of header-lines does not work well with what a HTTP message is per the book in RFC 2616. Which is perhaps actually a good practical use-case that such a PSR should be able to deal with fluently without introducing special-cases as Cookies are common in HTTP usage day-to-day.

I understand the value that is sometimes an array and sometimes a string as a* special-case*. These special-cases I normally want to shed away as far as possible. I would say this is important for a spec as well: It should magically make all those rough edges disappear to be a good guideline in day to day developer work when we implement it then in our projects.

So my 2 cents and I hope this makes my thoughts and feedback better understandable.