Re: [IPFIX] Encoding of Boolean values in draft-ietf-ipfix-text-adt

Brian Trammell <[email protected]> Thu, 27 Feb 2014 10:03:24 +0100
Newsgroups	gmane.ietf.ipfix
Message-ID	<[email protected]>
Paul, Juergen,

I'm okay with this. We can simply leave it unstated and up to reader implementers as to how much they want to follow the principle of liberal acceptance.

Cheers,

Brian

On 27 Feb 2014, at 09:48, Paul Aitken <[email protected]> wrote:

> Juergen,
> 
> Since there's potential for the 1/2 and "1"/"0" encodings to be confused, and since this is by definition a textual encoding, I'd prefer option 2 ("true", "false").
> 
> P.
> 
> 
> On 27/02/2014 08:42, Juergen Quittek wrote:
>> Hi Paul,
>> 
>> You are right. It is another pro for the true="1" and false="2" encoding that it is in line with RFC 7011. Thank you for pointing out this issue and sorry for not having this in my previous email.  For developers it would be a step of convenience to have encodings in line and use the one from SMI and RFC7011.
>> 
>> However, the textual representation addresses a larger community than just implementers. The textual representation is something that will be particularly interesting to people not very familiar with IPFIX encoding details. Here I think that the 1-2 encoding should not be used, because of its high potential to be not understood or misunderstood.
>> 
>> Cheers,
>>     Juergen
>> 
>>> -----Original Message-----
>>> From: Paul Aitken [mailto:[email protected]]
>>> Sent: Mittwoch, 26. Februar 2014 11:48
>>> To: Juergen Quittek; Brian Trammell
>>> Cc: IPFIX Working Group
>>> Subject: Re: Encoding of Boolean values in draft-ietf-ipfix-text-adt
>>> 
>>> Juergen,
>>> 
>>> The values in option 1 conflict with the RFC 7011 (IPFIX Protocol) boolean
>>> encoding definition, which says:
>>> 
>>> 
>>> 6.1.5.  boolean
>>> 
>>>    The boolean data type is specified according to the TruthValue in
>>>    [RFC2579].  It is encoded as a single-octet integer per
>>>    Section 6.1.1, with the value 1 for true and value 2 for false.
>>>    Every other value is undefined.
>>> 
>>> Option 3 provides the benefits of consistency with RFC 7011, and no
>>> conversion required between the RFC 7011 and text-adt formats.
>>> 
>>> Expressed another way: the IPFIX WG group already decided the boolean
>>> encoding. Although we might not like that definition now, we should
>>> consistently use the same encoding across all the IPFIX RFCs.
>>> 
>>> P.
>>> 
>>> 
>>> On 26/02/2014 10:18, Juergen Quittek wrote:
>>> 
>>> 
>>> 	Dear all,
>>> 
>>> 	The open question is: What is the best textual encoding for Boolean
>>> values in flow records?
>>> 
>>> 	Here are the alternatives discussed so far:
>>> 
>>> 	1. true: "1", false: "0"
>>> 	Pro: very common, used by several programming languages,
>>> international (not language-specific)
>>> 	Con:  0 may be misinterpreted as "don't know"
>>> 
>>> 	2. true: "true", false: "false"
>>> 	Pro: very common, unambiguous, used by several programming
>>> languages,
>>> 	Con:  not international: English language-specific
>>> 
>>> 	3. true:"1", false: "2"
>>> 	Pro: in line with SMI encoding for Booleans
>>> 	Con: unknown outside of SNMP community. Not intuitively clear
>>> which is true and which is false
>>> 
>>> 	4. true: "t"*, false: "f"*
>>> 	Con: may be confusing or misleading.
>>> 
>>> 	Writing now as technical contributor, I would eliminate option #4
>>> because I do not see any advantage of this alternative. #3 has only a weak
>>> "pro" being used by SMI.  Thus, we should either choose #1 or #2. Here, I
>>> would go for #1 because it is not language-specific.
>>> 
>>> 	Cheers,
>>> 	    Juergen
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 		-----Original Message-----
>>> 		From: IPFIX [mailto:[email protected]] On Behalf Of
>>> Paul Aitken
>>> 		Sent: Dienstag, 11. Februar 2014 22:32
>>> 		To: Brian Trammell
>>> 		Cc: IPFIX Working Group
>>> 		Subject: Re: [IPFIX] Fwd: New Version Notification for draft-
>>> ietf-ipfix-text-
>>> 		adt-01.txt
>>> 
>>> 		Brian,
>>> 
>>> 		Aside from the fact that this is English-specific, it works for
>>> me.
>>> 
>>> 		P.
>>> 
>>> 
>>> 
>>> 			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.
>>> 
>>> 
>>> 
>>> 	_______________________________________________
>>> 		IPFIX mailing list
>>> 		[email protected]
>>> 		https://www.ietf.org/mailman/listinfo/ipfix
>>> 
> 
> _______________________________________________
> 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)