Re: [Jcardcal] Genart LC review: draft-ietf-jcardcal-jcal-09

Robert Sparks <rjsparks@nostrum.com> Wed, 26 March 2014 13:22 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: jcardcal@ietfa.amsl.com
Delivered-To: jcardcal@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CA81A0113; Wed, 26 Mar 2014 06:22:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fVmLn8QloLF; Wed, 26 Mar 2014 06:22:20 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6576F1A0326; Wed, 26 Mar 2014 06:22:20 -0700 (PDT)
Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2QDMAdk067725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Wed, 26 Mar 2014 08:22:10 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88] claimed to be unnumerable.local
Message-ID: <5332D481.5070207@nostrum.com>
Date: Wed, 26 Mar 2014 08:22:09 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Philipp Kewisch <kewisch@gmail.com>, "<gen-art@ietf.org> Team" <gen-art@ietf.org>, draft-ietf-jcardcal-jcal@tools.ietf.org, "jcardcal@ietf.org" <jcardcal@ietf.org>
References: <531F5C0D.5040903@nostrum.com> <532B5066.5050803@gmail.com> <532B69C8.305@nostrum.com> <532B792D.7010105@gmail.com> <532C3BC1.1000909@nostrum.com> <5332A5E7.6040403@gmail.com>
In-Reply-To: <5332A5E7.6040403@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/jcardcal/o21lO-D4R3rlFercZcgnh0eUqD8
Subject: Re: [Jcardcal] Genart LC review: draft-ietf-jcardcal-jcal-09
X-BeenThere: jcardcal@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: JSON data formats for vCard and iCalendar WG <jcardcal.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jcardcal>, <mailto:jcardcal-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jcardcal/>
List-Post: <mailto:jcardcal@ietf.org>
List-Help: <mailto:jcardcal-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jcardcal>, <mailto:jcardcal-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Mar 2014 13:22:22 -0000

I'll let you work that out with Pete.

If you do decide to list them, I wouldn't repeat their definition.
The important thing is that you verified there wasn't anything left 
dangling.
Thanks for taking the time to go through that again.

RjS

On 3/26/14, 5:03 AM, Philipp Kewisch wrote:
> On 3/21/14, 2:16 PM, Robert Sparks wrote:
>> On 3/20/14, 6:26 PM, Philipp Kewisch wrote:
>>> On 3/20/14, 11:20 PM, Robert Sparks wrote:
>>>>> value-separator is defined in section 2 of rfc 7159.
>>>> Provide that reference at the point it's used in the document please.
>>> Just above the ABNF in the introduction to the section, I write "ABNF
>>> Symbols not described here are taken from [RFC7159]". Isn't that
>>> sufficient?
>> I missed it. Others are likely to as well.
>> Building an explicit list of what symbols you're counting on from that
>> document
>> would let you check that you haven't missed defining any others.
>> Putting the list
>> in the document will help others later find where to go when they're
>> missing the
>> symbol by using grep on this document.
>> (You should have that list already from the ABNF verification step you
>> performed).
>>> Philipp
> That list is quite a bit, I personally think the note at the beginning
> of the section should be sufficient. Don't you think most implementers
> will assume these rules belong to JSON and re-read the section if they
> are really looking for why the rule is missing? If you think this is a
> blocking issue, I'm happy to include it though.
>
> ; These symbols originate from RFC7159 and are only
> begin-array     = ws %x5B ws  ; [ left square bracket
> begin-object    = ws %x7B ws  ; { left curly bracket
> end-array       = ws %x5D ws  ; ] right square bracket
> end-object      = ws %x7D ws  ; } right curly bracket
> name-separator  = ws %x3A ws  ; : colon
> value-separator = ws %x2C ws  ; , comma
> string = quotation-mark *char quotation-mark
> quotation-mark = %x22      ; "
> ws = *( %x20 / %x09 / %x0A / %x0D ) ; Space, Horizontal tab, line feed
>                                      ; or new line, carriage return
> false = %x66.61.6c.73.65   ; false
> true  = %x74.72.75.65      ; true
> number = [ minus ] int [ frac ] [ exp ]
> decimal-point = %x2E       ; .
> digit1-9 = %x31-39         ; 1-9
> e = %x65 / %x45            ; e E
> exp = e [ minus / plus ] 1*DIGIT
> frac = decimal-point 1*DIGIT
> int = zero / ( digit1-9 *DIGIT )
> minus = %x2D               ; -
> plus = %x2B                ; +
> zero = %x30                ; 0