IPP Mail Archive: Re: IPP> SLP 'printer:' template comments [language]

IPP Mail Archive: Re: IPP> SLP 'printer:' template comments [language]

Re: IPP> SLP 'printer:' template comments [language]

Ira McDonald (imcdonal@sdsp.mc.xerox.com)
Wed, 13 Jan 99 15:31:58 EST

Hi Erik and James,

SLPv1 (RFC 2165) is NOT compliant with RFC 2277 (IETF Policy on Charsets
and Languages), because it does NOT support full RFC 1766 language tags.
It has two character ISO 639 language codes, but NOT ISO 3166 territory
codes, required for both RFC 1766 language tags and the closely related
ISO 9945-1 (POSIX.1) locale tags.

On the other hand, IPP/1.0 is RFC 2277 compliant (all names and all
text are always in explicit language contexts, with RFC 1766 tags).

The IPP WG's basic purpose in revising the SLP 'printer:' abstract
service template is that, when we finish editing it, we then decompose
it into concrete protocol templates for SLPv1 interworking usage.
Therefore, the SLP 'printer:' attribute with a full RFC 1766 language
tag, 'natural-language-configured', remains necessary and mandatory.

Separately, the attribute 'natural-language-supported' (mandatory for
all IPP Printer objects) is necessary in the 'printer:' template, so
that the obtained 'service:' URL is actually usable. If the value of
'natural-language-configured' is a language NOT supported by a given
client, then that client must FIRST request from the IPP Printer object
the 'natural-language-supported' attribute BEFORE any useful work,
which is contrary to the intended usage of SLPv1/SLPv2.

- Ira McDonald (outside consultant at Xerox)
High North Inc

Erik Guttman wrote:
> Date: Tue, 12 Jan 1999 16:43:58 -0800
> From: erik guttman <erik.guttman@sun.com>
> To: Ira McDonald <imcdonal@sdsp.mc.xerox.com>
> CC: HPARRA@novell.com, ipp@pwg.org, srvloc@srvloc.org,
> Subject: Re: IPP> SLP 'printer:' template comments
> Ira and others,
> SLP service de/registrations and requests are all language tagged.
> This means that the attributes and other strings which are transported
> by SLP are always explicitely language specific. This is in full
> conformance with RFC 2277. There is no need to include an attribute
> identifying the language of the other attributes since there is an
> explicit language tagging used in every SLP message. This language
> tag is exactly that specified by RFC 1766.
> Erik
> Ira McDonald wrote:
> >
> > Hi Hugo,
> >
> > Thanks for the quick and thorough response.
> >
> > Let me comment on 'natural-language-configured'. Like ALL of
> > the IPP-derived attributes in the SLP 'printer:' template, it
> > is meant to accurately reflect the actual configuration of
> > the IPP Printer object. However, since SLP (and LDAP) don't
> > have any standard base datatype 'textWithLanguage', the
> > 'natural-language-configured' attribute does double duty
> > to specify the language of SLP (and IPP Printer object)
> > attributes with 'textWithLanguage' or 'nameWithLanguage'
> > (such as site-administered media names, which are very
> > important in enterprise printing environments).
> >
> > This is conformant with RFC 2277 (IETF Policy on Charsets
> > and Languages) which MANDATES that all application protocols
> > which transfer text shall explicitly convey the language
> > of that text. It is NOT optional for an IETF standards-track
> > document to put language-tags on text attributes. It is
> > a requirement to stay on the Internet 'standards track'.
> >
> > We COULD have a separate attribute for the language
> > of the SLP 'printer:' template text and site-name
> > attributes, but it seems an entirely reasonable simplification
> > to presume that a system administrator would: 1) install
> > a network printer (connectivity setup); 2) set the
> > 'natural-language-configured' of that printer; and 3) set
> > various site-specific info attributes of that printer.
> > So the current SLP 'printer:' template makes sense.
> >
> > What do you think?
> >
> > Cheers,
> > - Ira McDonald (outside consultant at Xerox)
> > High North Inc
> > 716-461-5667 (w/ voice mail)
> ----------------------------------------------------------------------
> Erik Guttman Germany: +49 7263 911 701
> Sun Microsystems - Advanced Network Development USA: +1 650 786 5992