Hi Bill,
Your proposed wording for I18N section is fine.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Mon, Jul 19, 2010 at 1:30 PM, William Wagner <wamwagner at comcast.net> wrote:
> Ira,
>> I am confounded by the use of the term "future Imaging Services". For
> simplicity sake, I had put in your suggestion about "future services" in the
> draft sent for last call, and it did elicit some comments. Taken literally
> this appears to refer to some "future service" other than Print, Scan, etc
> (i.e., the Imaging Services identified in this requirement document) If that
> is what is intended, it seems hardly appropriate in a requirements document
> for the modeling of these services. If it means to refer to new designs of
> devices supporting the addressed Imaging Services, I think that is also
> inappropriate. It was my understanding that this requirements document is
> supposed to address the requirements for and of the MFD Imaging Services
> Models, not some future Imaging Services and not directly for MFDs. And
> since it is supposed to precede the document generation, one may assume that
> it might be fairly general in its outline.
>> If there is insistence on putting something in sections 7 and 8, and if it
> is agreed that this may be a general statement, not a summary of things
> embedded in the previous sections, then I suggest something like the
> following which is derived from corresponding sections of the already
> approved MFD Imaging Service model documents. I might also note that the
> Scan and Resource Service Model and Interface documents had no mention of
> registration or internationalization (or security) in the Rationale or
> Requirements sections that were included in the place of a Requirements
> document.
>> Bill Wagner
> =====================================
>> 7 IANA and PWG Considerations
> Once a Imaging Services Model specification and associated schema is
> approved and published, the registration of extensions to the Service model
> defined in that specification will require a revision to that specification.
> Vendors may use extensions in their own namespace until such time as an
> update to the specification is under review.
>> 8 Internationalization Considerations
> The Imaging Services Model specifications will identify element values
> defined by enumerations (e.g. State) that represent keywords. Keywords are
> never localized by the device. A <service> Client may convert the values
> into a form acceptable to the User. This conversion may include not only
> localization but also transformations into graphical representation.
>> In each operation request, the <service> Client identifies a natural
> language that applies to the Imaging Service generated strings returned by
> the Service in operation responses. The Service must provide the localized
> value as requested by the user for any supported natural languages. A
> request for a language not supported results in a response with the string
> in the default localization.
>> No localization is performed on string values supplied by an administrator
> or End User. These strings are returned in operation responses as they were
> sent by the administrator or End User.
>> ==========================
>> -----Original Message-----
> From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of Ira
> McDonald
> Sent: Friday, July 16, 2010 1:16 PM
> To: mfd at pwg.org; Ira McDonald
> Subject: [MFD] Internationalization Considerations for MFD Requirements
> document
>> Hi,
>> I suggest the following text:
>> "An MFD is a network device that frequently generates description and
> status attributes
> that contain human-readable text for Jobs and Services. The design of
> future Imaging
> Services should require support for human-readable text in UTF-8 [RFC 3629].
> The design of future Imaging Services should NOT allow or encourage
> the use of any
> other encoding for human-readable text, in order to improve
> interoperability."
>> Cheers,
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
>http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc> mailto:blueroofmusic at gmail.com> winter:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> summer:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>> _______________________________________________
> mfd mailing list
>mfd at pwg.org>https://www.pwg.org/mailman/listinfo/mfd>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.