Re: AD review draft-ietf-imapapnd-appendlimit-extension-06

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?

- 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:[email protected]] On Behalf Of Alexey
>> Melnikov
>> Sent: Thursday, December 17, 2015 5:16 AM
>> To: [email protected]
>> Subject: Re: [imapext] AD review of
>> draft-ietf-imapapnd-appendlimit-extension-06
>>
>>
>>> On 17 Dec 2015, at 03:39, Adrien de Croy <[email protected]> wrote:
>>>
>>> ------ Original Message ------
>>> From: "Barry Leiba" <[email protected]>
>>> To: "Bron Gondwana" <[email protected]>
>>> Cc: "[email protected]" <[email protected]>
>>> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/imapext

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext