For the last two years, the IETF has mandated that
all human-readable content in _new_ IETF protocols
(and IPP notification is new, even if it uses
existing transport mechanisms for delivery) MUST
be language-tagged and (if other charsets than
UTF-8 are allowed) also charset tagged.
See: IETF Policy on Character Sets and Languages
RFC 2277 / BCP 18 (January 1998)
This policy does NOT mandate that systems must support
negotiation for language in replies (by my reading),
just RECOMMENDS it. But since IPP notifications _do_
support negotiation for language in notifications,
I believe the issues of internationalization should
be addressed in the IPP 'mailto:' notification spec.
I apologize for appearing to be 'self-appointed expert'
on IETF matters. I do participate regularly in five
IETF chartered working groups and I do pay attention
to comments from IESG members on design issues.
- Ira McDonald
From: Jay Martin [mailto:jkm at underscore.com]
Sent: Friday, August 18, 2000 8:09 PM
To: McDonald, Ira
Cc: ipp at pwg.org
Subject: Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
TheIPPNotification I-Ds will now go the IESG)]
Since you're the self-declared expert on all things IETF,
what is the current position of the IETF on producing protocols
that don't support I18N? Does the IETF mandate that all human-readable
elements of protocol data support I18N, or merely frown upon it?
Or do that *not* mandate it at all? Just curious.
"McDonald, Ira" wrote:
>> Hi Jay,
>> The IPP 'mailto:' notification method recommends
> suitable content for the human-readable notification,
> while gracefully dodging the issues of I18n for
> tagging of that content.
>> How does a user know that the next few characters
> are 'job-id' rather than something else?
> Are there 'labels' that are translations of the intent
> (if not the name) of IPP attributes in the notification?
>> Is the notification an actually linguistically correct
> _whole_sentence_ in the target notification language?
> How can we have a standardized email notification
> that doesn't address the human usability of the
> - Ira McDonald
>> -----Original Message-----
> From: Jay Martin [mailto:jkm at underscore.com]
> Sent: Friday, August 18, 2000 6:51 PM
> To: McDonald, Ira
> Cc: 'ned.freed at innosoft.com'; ipp at pwg.org> Subject: Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
> TheIPPNotification I-Ds will now go the IESG)]
>> No one ever, *ever* said I18N in mail messages wasn't difficult.
> Don't know how you came to that conclusion.
>> In fact, with the exception of Tom Hastings (big surprise),
> there hasn't been a word said on this thread by anyone
> else about I18N in email notifications, except for your
> comments and the interesting side comment by Ned.
>> "McDonald, Ira" wrote:
> > Hi Ned,
> > Thanks - you're the only person who has reinforced my
> > periodic comments that the I18N for the stuff in the
> > 'simple text' email notifications is a nice juicy
> > problem - since IPP and most (or all?) shipping IPP
> > Printer implementations define support for multiple
> > human languages and charsets.
> > And the fact that a client can ask for a notification
> > in some other charset than UTF-8 further complicates
> > I18N, because the obvious starting point (message
> > catalogs in UTF-8) leads to smashed characters in
> > many local charsets.
> > I think the IPP 'mailto:' notification method should
> > be a good deal more complete on this I18N topic.
> > Cheers,
> > - Ira McDonald, consulting architect at Xerox and Sharp
> > High North Inc
> > -----Original Message-----
> > From: ned.freed at innosoft.com [mailto:ned.freed at innosoft.com]
> > Sent: Friday, August 18, 2000 8:21 AM
> > To: pmoore at peerless.com> > Cc: David_Kellerman at nls.com; kugler at us.ibm.com; ipp at pwg.org> > Subject: Re: IPP>NOT mailto feature from IETF meeting (RE: IPP> ADM -
> > TheIPPNotification I-Ds will now go the IESG)]
> > <...snip...>
> > Frankly, the bigger problem with this stuff is i18n support for the
> > But that's a different topic.
> > IMO the supposed difference between simple text and a structured report
> > chimera. Email support in general is another matter, of course.
> > Ned