[IDS] Updated stable draft of IDS Common Log posted

[IDS] Updated stable draft of IDS Common Log posted

Michael Sweet msweet at apple.com
Thu May 14 00:00:10 UTC 2015


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



More information about the ids mailing list