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

[SM <[e-mail]>]

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.

Agreed.

>    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".

Regards,
-sm