The NL parameter represents the natural language used for generating the message content - parameters are considered unlocalized, even for things like UserName. Typically that means the IPP natural-language-configured Printer attribute value, although for some implementations (like CUPS) we will localized job-state-message and notify-text values using the natural language associated with the Job or Subscription objects, with natural-language-configured being the backup if the submission language is not supported.
I can probably clarify this in the LogNaturalLanguage definition, e.g.:
The LogNaturalLanguage specifies the language used for the MESSAGE content in the log line. Parameter values are not considered to be values localized by the Services of the Imaging Device.
> On May 13, 2015, at 12:36 PM, Rizzo, Christopher <Christopher.Rizzo at xerox.com> wrote:
>> Another question regarding PWG 5110.3 has come up.
>> The NL parameter - I presume this specifies the language of the log and
> not the language associated with the request that triggered the log entry
> (ie - a JobCreated event for an IPP Create-Job request that specifies
> attributes-natural-language != en).
>> If this does represent the language of the log, then do specific fields of
> the log need to be in that language, and if so what fields?
>> Christopher Rizzo
> Xerox Corporation MS 7060-368
> 26600 SW Parkway Ave.
> Wilsonville, OR 97070
> Phone: (503) 582-7577
> Intelnet: 8*872-7577
> Cube: 7060-Z22-C
> Email: Christopher.Rizzo at xerox.com>>>>> On 5/7/15, 6:19 AM, "Michael Sweet" <msweet at apple.com> wrote:
>>>> I'll be posting an updated draft today with corrections.
>>>>> On May 5, 2015, at 1:12 PM, Rizzo, Christopher
>>> <Christopher.Rizzo at xerox.com> wrote:
>>>>>> My comments:
>>>>>> 1. I don't understand why, but per March 2009 RFC5424 Section 6. Syslog
>>> Message Format there should be no space (SP) between Priority (PRI) and
>>> Version (VERSION) in the header (HEADER). So examples should be like:
>>> "<66>1 ..." not "<66> 1 ...".
>>>> Whoops, missed that...
>>>>> 2. Line 286 - "SecurityInvalidAuthenticationService" is not defined in
>>> section 5.1.2. Do events not have to be selected from section 5.1.2? I
>>> also could not find it in prtAlertCodeTC in the IANA Printer MIB or in
>>> 5107-3 (Printer Alerts). But seems this line should be something like
>>> E="<service>Authentication" S="ServerErrorServiceUnavailable" (picked
>>> RFC2911 section 13.1) where maybe <service>=Print unless it is not a
>>> requirement that events must be pre-defined. Or do we add a Security
>>> service to section 5.1.2?
>>>> No, that was a hypothetical thing; changing it to "PrintInternalError"
>> (and defining <service>InternalError in 5.1.2) to track internal
>> (configuration/accessibility/etc.) errors in a service.
>>>> The status code is only applicable for responses to a client request.
>>>>> 3. Line 293 - Line 381-383 imply S="client-error-not-authenticated"
>>> be in TitleCase form "ClientErrorNotAuthenticated". Same issue for line
>>>> Thanks, fixed!
>>>>> Maybe I'm being too picky about the examples?
>>>> No, they need to be correct, otherwise they aren't good examples (unless
>> I was trying to show bad messages, which I'm not... :)
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
Michael Sweet, Senior Printing System Engineer, PWG Chair