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

Hi Paul,

> -----Original Message-----
> From: Paul Aitken [mailto:[email protected]]
> Sent: Donnerstag, 27. Februar 2014 09:49
> To: Juergen Quittek; Brian Trammell
> Cc: IPFIX Working Group
> Subject: Re: Encoding of Boolean values in draft-ietf-ipfix-text-adt
> 
> Juergen,
> 
> Since there's potential for the 1/2 and "1"/"0" encodings to be confused, and

How could they get confused? 
A "1" means true in both encodings.

Cheers,
    Juergen

> 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