[PSR-3] LogLevel constant values vs. RFC 5424

[sun]

Hi everyone,

tl;dr:  The defined LogLevel constant values of PSR-3 violate the IETF standard it claims to adhere to, which causes interoperability problems within and beyond the scope of PHP software.  PSR-3 should be corrected to comply with IETF standards.  Correcting the php-fig/log sample implementation appears to be straightforward, but the PSR-3 document itself contains a literal copy of the constant values that need correction.  This issue hinders wide-spread adoption of PSR-3, as it forces all projects to diverge from a well-defined IETF interoperability standard.  It should be resolved as soon as possible, so as to avoid/prevent adoption of the current, erroneous PSR-3 spec.


PSR-3 is a great addition and truly enhances interoperability of PHP code.  However, it contains a problem that I want to bring to your attention, and which can (hopefully) be fixed through Errata.

The PSR-3 spec explicitly states that it implements the standard log message levels (severities) of RFC 5424:

The LoggerInterface exposes eight methods to write logs to the eight RFC 5424 levels (debug, info, notice, warning, error, critical, alert, emergency).

Indeed, PSR-3 follows RFC 5424 all over the place, even up to the point of literally copied text fragments.  However:

While the informational meanings/interpretations of log levels (severities) were taken over, the actual specification of severity values were not.  Instead of being represented by the standard {0-7} integers, the LogLevel class defines the constant values as strings.

This causes PSR-3 logger implementations to violate the IETF RFC 5424 standard.  Such implementations may be interoperable within the limited scope of software stacks that are exclusively driven by PHP, but interoperability ends with PHP.  Any other logger/log-related implementation that adheres to RFC 5424 needs to be adjusted to support PSR-3. — Interoperability does not end in writing log messages; something is going to read them.  PSR-3 forces all implementations (PHP or not) to (internally) correct this problem so as to ensure actual interoperability.

The divergence from the IETF standard was (somewhat) brought up very early in the PSR-3 proposal/discussion already.  Unfortunately, the concern wasn't raised as clearly and as concisely as it should have been (just some references to prior art + personal suggestions/opinions - vs. - adhering to a very clear IETF specification).  This caused the early change proposal to get ignored.

Interestingly, the change proposal was primarily rejected to [para-phrased] "ease adoption of PSR-3 for existing logger implementations." — However, after doing an extensive research to double-check many existing PHP frameworks and CMS/application projects, the vast majority does adhere to RFC 5424 and does use the log message severity integers as defined in the IETF standard. (The PR contains a detailed list.)  "Adopting PSR-3" means to knowingly diverge from the IETF standard for all of them, even though they did follow it previously.

Especially given that hard data point, it is not clear why PSR-3 diverged from RFC 5424.  At this point, I assume the table of log message severities in RFC 5424 6.2.1 was misinterpreted to not be a formal part of the specification.  However, the "Numerical code" column is an integral part of the specification. — In fact, only the second column is informational, as it only describes the intended/implied meaning of each severity level - if you wanted to, you could use different severity labels, as long as they encompass the same meaning of the numeric code/level.

RFC 5424 is the successor of RFC 3164, which exists and contains the identical definition since 2001.  The LOG_ constants of PHP core also follow the IETF standard (but note that they are unreliable, since different/emulated for syslog() on Windows, as outlined here and [barely] documented since 2002).

Given that php-fig is all about interoperability, it is very problematic that one of its standards diverges from the externally defined IETF standard that it wraps (and which goes way beyond the scope of PHP).  The numeric log message severities are implemented by almost all other languages/frameworks/applications, which is the whole point of an IETF interoperability standard.  Only PSR-3 diverges from it.

Correcting this ought to be a simple code change, since the public API remains the same.  But unfortunately, the very end of the PSR-3 spec contains a literal copy of the LogLevel class, including the constant values. (…not sure whether including that was a good idea.)

The concrete proposal is to

1. Fix php-fig/log in-place to use the standard log level/severity integers for the LogLevel constant values. (bumping the version to 2.0)
2. Correct the PSR-3 specification and amend it with Errata to clarify that the constant values were changed to comply with IETF RFC 5424.

The first part is prepared in https://github.com/php-fig/log/pull/21 (including results of above mentioned research)

The second part is a bit more hairy, since the concept of Errata and/or similar amendments was only discussed on theoretical grounds thus far.  It's not clear how a correction like this is supposed to be executed.  The adjustment does not affect consumers (since constant names remain the same), it only affects implementors/developers of actual logger implementations.  (Note that the research only yielded 1-2 projects that started to adopt PSR-3 already.)

Thus far, I've received very positive feedback on the proposed correction of PSR-3.  My interpretation is that most projects/people support the move, because their existing code follows RFC 5424 already, and this aspect of the current PSR-3 spec either caused problems for them or caused them to abandon the adoption of PSR-3 altogether.

Thoughts?

Thanks,
sun

---
Context: I'm a Drupal core developer.  Drupal wants to adopt PSR-3 for Drupal 8 (as well as PSR-5, if it happens in time).  This interoperability problem came up in the necessary rewrite of our logging code/architecture.  Larry Garfield (Crell) formally represents Drupal in php-fig.  However, this message and change request is not coordinated with Larry.

[sun]

To supply a more concrete surface for discussion, I created a PR against the PSR-3 specification itself to amend it with Errata:

https://github.com/php-fig/fig-standards/pull/282

[Robert Hafner]

TLDR: The LogLevel constants that were defined in PSR-3 used string descriptions ("info", "notice", "warning", etc) as their values while the standard it was modeled after defined them as integers. Changing the values of the constants to Integers would make PSR follow existing norms and improve the overall interoperability of the standard.

As my own thoughts, this seems like a very straight forward change that should have minimal backwards compatibility issues. The benefits of constants are that people use and test against them, not their values. That being said, this would be a BC break and would need to have the interface package versioned accordingly.

I think this is worth pursuing. 

Robert

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ff4ed498-ce01-4e5f-ac55-3b7186605ea4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[FGM at GMail]

To avoid changing the standard, thus opening a big can of worms, would it not be better to allow a second set of constants with the RFC numeric values, say LogLevelRfc5424 in an addendum (PSR-3.1 ? PSR-7 ?) with the RFC5424 values: that way PSR-3 consumers already using PSR-3 could continue using the LogLevel string constants, and implementations could support either, or be only compliant with PSR-3 or the addendum.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/A25AD55C-EEFA-4947-BD91-28AD0A988FA1%40tedivm.com.

[Phil Sturgeon]

As we do not modify standards themselves, and we do not release minor or patch versions of standards (PSR 3.1) this can not realistically be achieved without making a brand new PSR - by design.

You'd need to try and make this one PSR-9. I'd vote no.