Re: [imapext] AD review draft-ietf-imapapnd-appendlimit-extension-06

On 17/12/2015 17:37, Stu Brandt wrote:
> Since RFC 3501 section 4.5 states...
>
>    The special form "NIL" represents the non-existence of a particular
>    data item that is represented as a string or parenthesized list, as
>    distinct from the empty string "" or the empty parenthesized list ().
>
>
> ...does the introduction of nil as an alternative to number now imply 
> that an update to this text is necessary?
We can consider it, but I don't think this is actually a big deal. 
Because the text above doesn't say that "nil" can't be used anywhere 
else ;-).
>
> - Stuart
>
> On 12/17/15 12:20 PM, Alexey Melnikov wrote:
>> Hi,
>>
>> On 17/12/2015 17:01, Narendra Bisht wrote:
>>> The data type for APPENDLIMIT is NUMBER.
>>> Will it accommodate a NIL?
>>
>> RFC 3501 defines:
>> status-att-list =  status-att SP number *(SP status-att SP number)
>>
>>
>> RFC 4466 redefines status-att-list:
>> status-att-list = status-att-val *(SP status-att-val)
>>                       ;; Redefines status-att-list from RFC 3501.
>>
>> status-att-val  = ("MESSAGES" SP number) /
>>                       ("RECENT" SP number) /
>>                       ("UIDNEXT" SP nz-number) /
>>                       ("UIDVALIDITY" SP nz-number) /
>>                       ("UNSEEN" SP number)
>>                       ;; Extensions to the STATUS responses
>>                       ;; should extend this production.
>>                       ;; Extensions should use the generic
>>                       ;; syntax defined by tagged-ext.
>>
>> So, I think you should add RFC 4466 to Normative references, then add
>> the following to Section 5 of your draft:
>>
>> appendlimit-status-att-val = "APPENDLIMIT" SP (number / nil)
>> status-att-val /= appendlimit-status-att-val
>>                              ;; status-att-val is defined in RFC 4466
>>
>>>
>>> -----Original Message-----
>>> From: imapext [mailto:imapext-bounces@ietf.org] On Behalf Of Alexey
>>> Melnikov
>>> Sent: Thursday, December 17, 2015 5:16 AM
>>> To: imapext@ietf.org
>>> Subject: Re: [imapext] AD review of
>>> draft-ietf-imapapnd-appendlimit-extension-06
>>>
>>>
>>>> On 17 Dec 2015, at 03:39, Adrien de Croy <adrien@qbik.com> wrote:
>>>>
>>>> ------ Original Message ------
>>>> From: "Barry Leiba" <barryleiba@computer.org>
>>>> To: "Bron Gondwana" <brong@fastmail.fm>
>>>> Cc: "imapext@ietf.org" <imapext@ietf.org>
>>>> Sent: 17/12/2015 9:14:31 a.m.
>>>> Subject: Re: [imapext] AD review of
>>>> draft-ietf-imapapnd-appendlimit-extension-06
>>>>
>>>>>>> Why do we think there's anything wrong with using, say, the word
>>>>>>> "NONE" (either case-insensitive or case-sensitive; I don't care)?
>>>>>>> What's wrong with this?:
>>>>>>>
>>>>>>> C: t1 STATUS INBOX (APPENDLIMIT)
>>>>>>> S: * STATUS INBOX (APPENDLIMIT NONE)
>>>>>>> S: t1 OK STATUS completed
>>>>>> If you're going to do that, why not make it (APPENDLIMIT NIL), which
>>>>>> already has exactly the meaning that we want?
>>>>> Yes, I'd forgotten about the existing token "NIL".  I like that
>>>>> approach.
>>>> +1
>>>>
>>>> Definitely not a fan of overloading the meaning of magic numbers
>>> I don't think this is a particular important point (there are always
>>> limits of some kind), but I like NIL.
>>
>> _______________________________________________
>> imapext mailing list
>> imapext@ietf.org
>> https://www.ietf.org/mailman/listinfo/imapext
>
> _______________________________________________
> imapext mailing list
> imapext@ietf.org
> https://www.ietf.org/mailman/listinfo/imapext