[bfcpbis] Old comments on RFC 4582

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 16 April 2012 10:55 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D851021F873E for <bfcpbis@ietfa.amsl.com>; Mon, 16 Apr 2012 03:55:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.949
X-Spam-Level:
X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 bHN-wT6WByz0 for <bfcpbis@ietfa.amsl.com>; Mon, 16 Apr 2012 03:55:52 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F00B321F872E for <bfcpbis@ietf.org>; Mon, 16 Apr 2012 03:55:51 -0700 (PDT)
X-AuditID: c1b4fb30-b7b07ae000006839-25-4f8bfab68094
Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E5.0C.26681.6BAFB8F4; Mon, 16 Apr 2012 12:55:51 +0200 (CEST)
Received: from [131.160.36.128] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 12:55:50 +0200
Message-ID: <4F8BFAB6.2050900@ericsson.com>
Date: Mon, 16 Apr 2012 13:55:50 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Subject: [bfcpbis] Old comments on RFC 4582
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bfcpbis>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Apr 2012 10:55:53 -0000

Hi,

below you can find an old thread with comments on RFC 4582 that should
be fixed in the new revision of the spec.

Cheers,

Gonzalo


-------- Original Message --------
Subject: Re: RFC 4582 additional note
Date: Tue, 23 Jan 2007 13:55:14 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
To: Alfred ? <ah@tr-sys.de>
CC: jo@netlab.hut.fi,  drage@lucent.com
References: <200612301007.LAA23236@TR-Sys.de>
<200612301044.LAA23279@TR-Sys.de>

Hi,

good catch. I will also log this comment.

Thanks,

Gonzalo

Alfred ? wrote:
> Hello,
> in my first note on RFC 4582, by accident I have omitted an item
> initially intended to be included there.
> Here we go with it:
>
>
> (3)  duplicate text
>
> Section 13.1.1 of RFC 4582 contains two instances of the same
> paragraph: the last paragraph on page 49 -- up to line formatting /
> hyphenation -- is a replication of the third-to-last paragraph on
> the same page.
>
>
> Best regards,
>   Alfred.









-------- Original Message --------
Subject: Re: RFC 4582 (BFCP) ABNF issues
Date: Tue, 23 Jan 2007 13:50:27 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
To: Alfred ? <ah@tr-sys.de>
CC: jo@netlab.hut.fi,  drage@lucent.com
References: <200612301007.LAA23236@TR-Sys.de>

Hi Alfred,

regarding 1), I agree with you that it is a formally-allowed slight
abuse of ABNF. I will log your comments so that, if we need to revise
the spec at some point, we fix it.

Regarding 2), it is just a variation of [FLOOR-ID]. As you point out in
1), we could have used either [xxx] or *1(xxx) throughout the spec. It
is unfortunate that we have used both in the same spec. However, even if
this can be confusing, it is still correct. I will also log this comment
for a potential future revision.

Thanks a lot for your comments.

Best regards,

Gonzalo



Alfred ? wrote:
> Hello,
> after studying the recently published RFC 4582 (BFCP) authored
> by you, I'd like to report some concerns related to the ABNF
> found in that memo.
>
>
> (1)  general concern
>
> In ABNF, the notation   [ <group> ]   is a shorthand for:
>                      0*1( <group> )   or shortly:
>                       *1( <group> )  , i.e. zero or one of <group>.
>
> RFC 4582 repeatedly uses the ABNF notation,
>     "*[ <group> ]" ,
> literally meaning:
>     "any number of { zero or one occurrences of <group> }".
>
> Although formally allowed by the ABNF RFC 4234, IMHO this is
> some sort of slight abuse of ABNF;
> as in other places, RFC 4582 better should have used
>     "*( <group> )"
> instead of the above notation (maybe even omitting the
> parentheses -- but I do not recommend that, for clarity).
>
> This issue occurs in Figures 22, 24, 26, 28, 30, and 31..43 .
>
>
> (2)  (potential) specific issue
>
> RFC 4582 pervasively uses the "optional" ABNF,  "[<group>]" ,
> to denote optional syntax elements.  But there is one exception;
> in Section 5.3.8, on page 33, Figure 38 contains the line:
>
>                           *1(FLOOR-ID)
>
> It is not evident from the context whether this is just an
> accidential variation in the use of ABNF, i.e. intended to say:
>
>                           [FLOOR-ID]
>
> or if in fact it was intended to say:
>
>                           1*(FLOOR-ID)
>
> If the latter is true, the line in the RFC is in error and
> I strongly recommend that you submit, as soon as possible,
> an Author's Errata Note to the RFC Editor's RFC Errata web
> pages, to correct this issue.
>
> Please comment.
>
>
> Best regards,
>   Alfred H?nes.
>