[Top] [All Lists]

Re: Standardized tag (was: draft-klensin-rfc2821bis-10: ABNF discuss)

2008-07-04 01:30:05

At 14:12 03-07-2008, John Leslie wrote:
   At first blush, this seems sufficient if the ABNF says what we need
(mostly how to parse the "tag").

From RFC 2821:

  General-address-literal = Standardized-tag ":" 1*dcontent
  Standardized-tag = Ldh-str
            ; MUST be specified in a standards-track RFC
            ; and registered with IANA

  Let-dig = ALPHA / DIGIT
  Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig

In draft-10:

  General-address-literal  = Standardized-tag ":" 1*dcontent
  Standardized-tag  ; MUST be specified in a standards-track RFC
                    ; and registered with IANA

A few days ago, Frank suggested using:

  Standardized-tag = Let-dig [Ldh-str]

Or we could have:

 Standardized-tag = ALPHA *( ALPHA / DIGIT / "-" )

That should address the "how to parse" question.

   Obviously, the answer is "maybe". ;^)

Some people are exasperated when they hear the "maybe" answer. :-)

   Even purest garbage can be "valid". And, a lot of the time, we don't
even need to process the "address" for the mail system to function. At
first blush, I'd say it's sufficient to specify how to isolate the
string which constitutes the "address". We can punt to other document(s)
how to make sense of it.


   One shouldn't need to "fully understand the rationale" in order to
use this spec. But one _should_ find sufficient specification to know
how to parse the constituent parts.

I agree that the specifications should be clear about the "how to parse". I don't think we would do a good job of revising a specification like this one if we don't understand the rationale. We may overlook some specific cases if we do not know why the previous WG and those before them took a decision.

At 01:30 01-07-2008, Magnus Westerlund wrote:
However, my personal objection against this resolution of the error is
that it leaves use with a undefined rule that is intended for future
extensions. I see this as a interoperability issue as any parser
implemented according to the rules in this document will have the
potential to fail on any future tag. If one could clarify what possible
syntax that the future tags could have then this would not be an issue.

I posted a suggestion for Standardized-tag. Note that "there are many instances in which provisions in the text constrain or otherwise modify the syntax or semantics implied by the grammar".

<Prev in Thread] Current Thread [Next in Thread>