Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-00

[Alessandro Vesely <[e-mail]>]

On Mon 06/May/2013 22:43:54 +0200 Murray S. Kucherawy wrote:
> On Mon, May 6, 2013 at 9:29 AM, Alessandro Vesely <[e-mail]> wrote:
>> 2.3. *Authentication Identifier Field*
>>
>> I tend to associate syntax with production rules, so I'm unable to
>> make sense of the sentence:
>>
>>    This is similar in syntax to a fully-qualified domain name.
> 
> You're aware of how this works; what would you suggest?  The ABNF is
> "value" because it is usually an FQDN, but we also say that it doesn't have
> to be.

I cannot think of anything but saying that explicitly.  How about
merging the first two paragraphs?  E.g.:

   Every Authentication-Results header field has an authentication
   service identifier field ("authserv-id" above).  This refers to
   the authenticating service within a given ADMD.  For example, if
   the identifier is similar in syntax to a fully-qualified domain
   name, domain delegation semantics can be used to establish whether
   it belongs to an ADMD's name space.  This specification does not
   mandate how, but the identifier MUST correspond unequivocally to
   the ADMD that generates it and MUST pertain to exactly that one
   ADMD. ...

>>    The uniqueness of the identifier MUST be guaranteed by the ADMD
>>    that generates it and MUST pertain to exactly that one ADMD.
>>
>> What is actually required is not the "uniqueness" of the identifier,
>> but the ability to univocally identify the responsible ADMD using the
>> identifier.  I'd suggest to rephrase the sentence accordingly.
> 
> Are those not synonymous?

Not quite.  For example, a random number would satisfy the uniqueness
but can hardly refer to an ADMD.

> From the perspective of a module consuming this field, it has to be
> the case that such a module can safely assume that a field bearing
> the authserv-id it expects (or one of a set, perhaps) can be 
> trusted.

Right.  But then associating the field with a specific ADMD becomes
interesting only if you happen to mix the message streams from
multiple ADMDs (e.g. on a MUA).  In that case, /all/ ADMDs have to be
compliant, and they have to agree on interoperable naming conventions.


>>    The "policy" result would be returned if, for example, [SPF]
>>    returned as "pass" result, but the local policy check finds that
>>    the sender's policy is unacceptable (e.g. terminates with "+all").
> 
> I don't agree with including that specific example, as it encourages a
> particular local policy debate that I don't think this document should
> approach.

I thought abhorring +all was uncontroversial.

> Thanks!

You're welcome :-)