This looks good to me
Xerox Corporation MS 7060-368
26600 SW Parkway Ave.
Wilsonville, OR 97070
Phone: (503) 582-7577
Email: Christopher.Rizzo at xerox.com
On 5/13/15, 5:00 PM, "Michael Sweet" <msweet at apple.com> wrote:
>>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
>> (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
>> 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.
>>>> Message Format there should be no space (SP) between Priority (PRI)
>>>> 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?
>>>> 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
>>>>>> Thanks, fixed!
>>>>>>> Maybe I'm being too picky about the examples?
>>>>>> No, they need to be correct, otherwise they aren't good examples
>>> 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