Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords]

From: Shevek <[email-masked]>
Date: Fri, 16 Jul 2004 00:58:00 +0100 (BST)

On Tue, 22 Jun 2004, Michael R. Brumm wrote:

> 
> Greg Conner wrote:
> >(One sort of limiting factor about modifiers is that they are considered to 
> >be order-independent and the current spec encourages them to be placed at 
> >the end to make this clear.  If I were to propose any modification to the 
> >current spec, it would be to allow modifiers to be placed inline allowing 
> >for the possibility that they might apply/associate the terms appearing 
> >after them, if appropriate.  This minor change in the spec should not 
> >affect any current parser or published records and would just be a 
> >clarification...)
> 
> Out of all the SPF spec changes proposed in the name of "extensibility"
> in the last couple months, I'd have to say that IMHO, this is probably
> the most reasonable. I'd vote for it.

I have always felt that certain modifiers might have 'scope' to all the 
mechanisms following them. I agree with this proposal.

S.

-- 
Shevek                                    http://www.anarres.org/
I am the Borg.                         http://www.gothnicity.org/

---

From: Mark Lentczner <[email-masked]>
Date: Thu, 15 Jul 2004 18:33:04 -0700

> mechanisms following them. I agree with this proposal.

If you read the draft-ietf-marid-protocol-00.txt document you'll see 
that they have been added.  The wording to do so was far from minor, 
but this is so that people could implement parsers that don't have to 
be recoded when new modifiers are defined.  Essentially we had to 
define the allowable syntax of different modifier types even though 
there are no such modifiers now.

If people need clarification on either what the spec means, how one can 
write a parser now that doesn't change when new modifiers are 
introduced, or what the rationale behind the choices were, please ask.  
I'll be happy to elucidate.

	- Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
[email-masked]