Hi - > From: "Dylan N. Pierce" <dylanpierce at megared.net.mx> > To: <ltru at ietf.org> > Sent: Friday, July 08, 2005 4:09 PM > Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe)Private UseTags ... > How about a non-ridiculous middle ground? > > (3) "Private-use subtags require private agreement between parties > intending to use them. They MUST NOT be designed for distribution > outside of the private agreements for which they are intended. Tags > intended for wider distribution SHOULD be registered instead as > extensions with the [registration authority]. There MUST NOT be > consequences for any application which chooses to ignore private use > tags. Developers of private use tags should use great caution in > ensuring that their applications are aware of, and can handle, the > possibility of a conflicting private use tag from an external private > agreement which appears similar to one of their own." > > If we can't get rid of them, after all, the least we can do is ensure > that the poor working hacks like me receive a heads-up in unambiguous > language. Programmers /do/ read these things, but we can't always assume > they think through the implications well. No harm in throwing them a rope. ... As a technical contributor, I agree whole-heartedly with your rationale. I'd tweak the proposal a bit... (4) "Private-use subtags require agreement between parties intending to use them. They MUST NOT be distributed beyond the scope of the relevant agreements. Subtags intended for wider distribution MUST be registered. Developers of private-use subtags are warned that, despite this prohibition, private-use subtags might "leak" beyond the scope of the agreement defining them. This means that applications making use of private-use tags need to be able to cope with conflicting (same character sequence but differing semantics) and unknown private-use tags. Randy _______________________________________________ Ltru mailing list Ltru at lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.