I've done the Http header and its one of those Mime based headers that can have many dozen's of different types of fields. It seems unreasonable to have the header author define everyone of those fields as a separate accessor method. We need a better header container for those type of headers (http, SIP, Mail message, etc..)
The existing Http definition (found under tests directory), already keeps track of all those headers in a Map<String, String>. There is an accessor method to retrieve the map and then using normal map methods you can check for each field. I think that is the right approach since there are so many possible fields, and most of them are almost always not there. The JHeader.decodeHeader method properly sets the offset and length properties for each Http field, thus it is simply a matter of a normal numerical sort to get the present fields to display properly in a formatter.
A single AbstractMimeHeader baseclass can take care of all of those protocols at once, including http.
One currently unresolved issue with Http is the multi-part contents. I've been thinking about this quiet a bit, and it doesn't make any sense to implement multiparts as hardcoded embeded sub-headers, although that is how they appear. What I'm leaning towards is a new type of sub-header that can act as as a proxy (a surrogate) and place actual standalone headers as sub-headers. This will allow for example Http header to be completely standalone as a header after http and as an embeded sub-header for Http header's with multiparts.
New text handling in JBuffer seems to be working well for Http so that part is done and working.
Just some of the things I'm working on and thinking about.