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

Alessandro Vesely <vesely@tana.it> Tue, 07 May 2013 15:42 UTC

Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C09721F8F53 for <apps-discuss@ietfa.amsl.com>; Tue, 7 May 2013 08:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level:
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz8ek5u-i1Bm for <apps-discuss@ietfa.amsl.com>; Tue, 7 May 2013 08:42:11 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 07A8721F8F26 for <apps-discuss@ietf.org>; Tue, 7 May 2013 08:42:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367941328; bh=gSq7hXX9OPYS32ohCxP0462PSPId7uXMmZJoiQNTJSk=; l=2616; h=Date:From:To:References:In-Reply-To; b=XCJt9ZREqykiwz1On03WdSLNOS0Smh/f1SYZaQdL1bxVoCjWIAe3oViNxAA7ZyAou nk/VptrRD4O7pOnott42YMnR2qWQKvBMaQEQeuRi6Kj75B/rAV8uNzNodiY/38C8bq pu3UH1K2q9oVNqzp6m8rNbCh0Z58eCFL3UG+JYvk=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Tue, 07 May 2013 17:42:08 +0200 id 00000000005DC04B.00000000518920D0.00001957
Message-ID: <518920D0.1040705@tana.it>
Date: Tue, 07 May 2013 17:42:08 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <5187DA74.9020204@tana.it> <CAL0qLwaMWbLbgAquXXnC1a_CRgu4zUgHwykc71_on2-99eAxww@mail.gmail.com>
In-Reply-To: <CAL0qLwaMWbLbgAquXXnC1a_CRgu4zUgHwykc71_on2-99eAxww@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 May 2013 15:42:15 -0000

On Mon 06/May/2013 22:43:54 +0200 Murray S. Kucherawy wrote:
> On Mon, May 6, 2013 at 9:29 AM, Alessandro Vesely <vesely@tana.it> 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 :-)