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

["Murray S. Kucherawy" <[e-mail]>]

On Tue, May 7, 2013 at 8:42 AM, Alessandro Vesely <[e-mail]> wrote:

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

I'm about to post a new version with this section reworked a bit.  Let me
know what you think of it.


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

Sure it can; NetEase (a Chinese ESP) uses "163.com" as their domain name.
An authserv-id of just "163" would be fine.


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

That's actually only true if you plan to trust the A-R fields added by
other ADMDs.  Most commonly you'll only care about your own.


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

Probably, but it's not something this document needs to discuss in order to
be effective.

-MSK