RE: host-meta file format comments (draft-nottingham-site-meta-01)

(not sure how my work email got into this thread... but please replace it with this one)

> From: Mark Nottingham [mailto:mnot@yahoo-inc.com]
> Sent: Tuesday, February 10, 2009 4:21 PM
>
> On 11/02/2009, at 12:38 AM, Thomas Roessler wrote:
>
> >> As with HTTP headers, field-names are not case-sensitive,
> >> unrecognised field-names SHOULD be silently ignored when parsing
> >> this format, and ordering of fields SHOULD NOT be considered
> >> significant unless specified otherwise. Additionally, although the
> >> syntax does not explicitly allow empty lines between fields,
> >> parsers SHOULD silently discard them (i.e., be permissive in what
> >> they accept). Field content is constrained by the specification
> >> indicated by its associated field-name.
> >
> > What's the cost of just permitting empty lines between fields in the
> > sytnax vs having the current "SHOULD parse"?  The current text
> > sounds like a gratuitous interop problem to me.
>
> Yeah, I'm not completely happy with it yet. The thought was that since
> blank lines don't introduce ambiguity here, they're not harmful. OTOH
> one of my goals for the format is to allow existing HTTP header and
> MIME parsers (e.g., in Python) to be used on the format, and they very
> well may barf on a blank line.
>
> So, the right thing to do might be to explicitly disallow them, both
> in BNF and prose. Eran, thoughts?

I wanted to either allow in both or explicitly disallow in both. Allowing them has the advantage of disabling the ability to stick other payload after the line break. But I see the logic in following the HTTP header structure which was my original inspiration for this general structure. I would say I am neutral with slight lean towards disallowing.

EHL

Received on Wednesday, 11 February 2009 07:23:01 UTC