Chris,
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?
>> Thanks,
> Chris
>> 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:
>>> Chris,
>>>> 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:
>>>>>> Michael,
>>>>>> 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
>>> PWG
>>> 5107-3 (Printer Alerts). But seems this line should be something like
>>> E="<service>Authentication" S="ServerErrorServiceUnavailable" (picked
>>> from
>>> 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"
>>> should
>>> be in TitleCase form "ClientErrorNotAuthenticated". Same issue for line
>>> 299,
>>>> 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
Our website uses cookies on your device to give you the best user experience. By using our website, you agree to the placement of these cookies. To learn more, read our privacy policy. Read Privacy Policy