Re: [IPFIX] [Sender: "IPFIX" <[email protected]>] Fwd: New Version Notification for draft-ietf-ipfix-text-adt-01.txt

Brian Trammell <[email protected]> Tue, 11 Feb 2014 22:11:33 +0100
Newsgroups	gmane.ietf.ipfix
Message-ID	<[email protected]>
On 11 Feb 2014, at 21:32, Paul Aitken <[email protected]> wrote:

> Brian, some suggestions:
> 
> 
> 1. true = 1, false = { anything else }
> 
>     - works with both the usual 0/1 convention and the IPFIX 1/2 convention

Much as I hate to propogate the idea the "2 is false" is anything other than a terrible, terrible idea, I like the approach. The issue I have with it is that the string "true" is false, which seems error-prone; the bigger issue I have with it is that every other type has a set of acceptable values and a set of unacceptable values. We don't for example say that any unparseable string for an unsigned8 is 0.

I'd be slightly more okay with this being encoded as an unsigned8, where 0 is false and any nonzero value is true, but this means we have two different encodings one of which has "2 is false" and the other has "2 is true", and I don't like that either.

We could say true = 1 and false = 0 | 2 but then we need to explain that we're carrying forward something from 7011 encoding, which we do for no other type.

So to be unambiguous, I'm starting to lean in the direction of:

> 2. true = "true", false = "false"
> 
>     - quite unambiguous
> 
> 
> 3. true = "t", false = "f"
> 
>     - shorter

Aside from the fact that these aren't case-insensitive (which at least causes an error as opposed to a non-detected incorrect acceptance), I'd say we could combine these:

true = ('t' | 'T') 0*ALPHA

false = ('f' | 'F') 0*ALPHA

i.e., the decoder only looks at the first letter for [tT] or [fF], probably with a note that "true" and "false" are the preferred encodings.

Thanks, cheers,

Brian

> P.
> 
> 
> On 11/02/2014 14:54, Brian Trammell wrote:
>> Greetings, all,
>> 
>> This revision addresses WGLC comments to date; left open is the representation of boolean-true and boolean-false, which I’ve kept at the literal integer values “1” and “0” respectively, because it’s not clear to me there’s a better resolution that’s consistent with the rest of the document.
>> 
>> WGLC continues up to the 14 Feb deadline.
>> 
>> Best regards,
>> 
>> Brian
>> 
>> Begin forwarded message:
>> 
>>> From: [email protected]
>>> Subject: New Version Notification for draft-ietf-ipfix-text-adt-01.txt
>>> Date: 11 Feb 2014 15:51:58 GMT+1
>>> To: "Brian Trammell" <[email protected]>, Brian Trammell <[email protected]>
>>> 
>>> 
>>> A new version of I-D, draft-ietf-ipfix-text-adt-01.txt
>>> has been successfully submitted by Brian Trammell and posted to the
>>> IETF repository.
>>> 
>>> Name:
>>> 
>>>               
>>>  draft-ietf-ipfix-text-adt
>>> Revision: 01
>>> Title:
>>> 
>>>               
>>>  Textual Representation of IPFIX Abstract Data Types
>>> Document date: 2014-02-11
>>> Group:
>>> 
>>>               
>>>  ipfix
>>> Pages:
>>> 
>>>               
>>>  13
>>> URL:            http://www.ietf.org/internet-drafts/draft-ietf-ipfix-text-adt-01.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-ietf-ipfix-text-adt/
>>> Htmlized:       http://tools.ietf.org/html/draft-ietf-ipfix-text-adt-01
>>> Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-text-adt-01
>>> 
>>> Abstract:
>>>   This document defines UTF-8 representations for IPFIX abstract data
>>>   types, to support interoperable usage of the IPFIX Information
>>>   Elements with protocols based on textual encodings.
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> The IETF Secretariat
>> 
>> 
>> 
>> _______________________________________________
>> IPFIX mailing list
>> 
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ipfix
>

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix
signature.asc (application/pgp-signature, 496 B)