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

Hi Brian,
What do you mean with "leaving it unstated"?
Not fixing the textual encoding?
Cheers,
    Juergen

> -----Original Message-----
> From: Brian Trammell [mailto:[email protected]]
> Sent: Donnerstag, 27. Februar 2014 10:03
> To: Paul Aitken
> Cc: Juergen Quittek; IPFIX Working Group
> Subject: Re: [IPFIX] Encoding of Boolean values in draft-ietf-ipfix-text-adt
> 
> 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