Subject: RE: [Ltru] Re: The most perverse tag

From: "McDonald, Ira" <[email-masked]>
Date: Sun, 5 Jun 2005 12:20:04 -0700

Hi,

In printing industry protocols, the following is the current
state of length limitations on language tags:

IPP/1.0 (RFC 2565/2566) and IPP/1.1 (RFC 2910/2911)
- defines the over-the-wire datatype 'naturalLanguage' 
  (maximum length 63 octets)

Job Monitoring MIB (RFC 2707)
- defines the textual convention 'JmNaturalLanguageTagTC'
  (maximum length 63 octets)

Printer MIB v1 (RFC 1759) and Printer MIB v2 (RFC 3805)
- defines the 'prtLocalizationTable' containing the columnar
  objects 'prtLocalizationLanguage' (max length 2 octets)
  and 'prtLocalizationCountry' (max length 2 octets)

[Obviously, Printer MIB should _not_ be considered by LTRU WG
- I argued unsuccessfully during Printer MIB v2 development
to fix the broken language tags.]

But language tag datatypes in IPP and the Job Monitoring MIB
have been copied into almost every modern printing standard
(from Bluetooth on the low end to CIP4 JDF production printing
on the high end) and many private consortium printing specs.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Randy Presuhn
> Sent: Saturday, June 04, 2005 8:19 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] Re: The most perverse tag
> 
> 
> Hi -
> 
> > From: "Doug Ewell" <[email-masked]>
> > To: "LTRU Working Group" <[email-masked]>
> > Sent: Saturday, June 04, 2005 10:44 AM
> > Subject: [Ltru] Re: The most perverse tag
> >
> 
> > Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:
> >
> > > | Implementations MUST be able to handle tags of this length
> > > | without truncation.  Support for tags of up to 64 characters
> > > | is RECOMMENDED. Implementations MAY support longer tags.
> > >
> > > The MAY is obvious, that could be deleted.  The RECOMMENDED is
> > > fine.  But what's the purpose of the MUST ?  We know that it's
> > > impossible for an encoded word in a MIME header field line.
> >
> > He's right.  We might be within our bounds to require this for new
> > applications, but we can't retrofit it onto existing 
> applications that
> > don't already support it.
> >
> > The rules for intelligent truncation would probably apply 
> here (do not
> > chop a subtag in half, consider removing extensions before 
> other things,
> > publicly state the limit to which truncation occurs).
> ...
> 
> If the current number is not acceptable, what IS the minimum 
> beyond which
> conformant implementations MUST NOT truncate?
> 
> As a technical contributor, I don't find the limitations of 
> existing applications
> very persuasive, since we're adding features.  I *do* find 
> the limitations of
> existing *protocols* that use language tags more relevant, 
> (though not decisive)
> since they will have a longer term impact on what can 
> actually be used.
> However, if we learn that protocol FOO, for example, uses 
> language tags and has
> a field of at most 3 octets to hold them, we should think 
> hard before letting
> that be the tail that wags this dog.
> 
> Randy
> 
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru
> 

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 05 Jun 2005 23:02:34 +0200

>   (maximum length 63 octets)

We could RECOOMMEND 63 instead of 64.  And keep "MAYbe more,
maybe not" separate as it is in -03, and as Doug wants it.  

With an old magic number 63 we don't need a new 64 when what
we really want is "at least 62" ;-)

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 5 Jun 2005 15:19:37 -0700

I have no problem with a recommended minimum of 63.

‎Mark