Re: Header Structure: goals

On 2017-06-14 17:51, Mark Nottingham wrote:
> Picking this thread back up, my personal (not chair) observations...
> 
> I'd thought that the purpose of surveying existing headers in the draft was to learn commonly used structures, so as to help make what we come up more familiar (and thus easier to use), not to come up with something that will replace existing header definitions.
> 
> To me, the most important thing we're doing here is creating tools / guidelines for authors of *new* header fields to use, so that they don't a) fall into the many pitfalls of doing so, and b) reduce work/problems for implementers when generating/processing those headers.
> 
> (b) very well may involve specifying syntax.
> 
> Future consolidation of existing headers is a nice-to-have, but as discussed quite a bit, may require some awkwardness that makes it undesirable. My understanding was that this was a non-goal for this work.
> 
> Likewise, creating another header serialisation / compression that takes advantage of what we do is something we should keep an eye on, but isn't an immediate goal.
> 
> I don't *think* there's anything new above; it was discussed quite a bit in the threads leading up to PHK's draft (which AFAICT we adopted because it was going in a non-JSON direction). However, it seems like we're drifting back into that discussion again.
> 
> Chair hat back on -- Please discuss. We've gone back and forth significantly on this, so it'd be good to get a crisp set of goals that we can agree to in the draft.
> 
> Cheers,

We are clearly not making sufficient progress solving the problem we 
wanted to solve - to make it easier to define new header fields with a 
syntax that is not "broken" and where processors can use off-the-shelf 
components to do the parsing.

Note that this is not a complaint vs PHK - it's a WG working item after 
all. Without concrete feedback, it's hard to make progress.

Best regards, Julian

Received on Friday, 16 June 2017 07:03:00 UTC