Subject: [Ltru] Suggested text for future compatibility of registry processors.

From: "Mark Davis" <[email-masked]>
Date: Sun, 1 Jul 2007 16:18:30 -0700

Doug noted the following in his email on UTF-8 (on which topic I agree with
him, btw).

> Addison is correct; any structural change to the Registry will break RFC
4646-conformant processors.  This is true not only for UTF-8, but also for
new fields such as "Macrolanguage" or "Modified."  (Section 3.1 says the
Type "MUST" be one of the seven currently defined values.)

I suggest that we add language to 4646bis noting this, with the following
suggested text.

Add to the end of 3.1.2.  Record Definitions:

Future versions of the language subtag registry may add more fields.
Processors of the registry that are not intended to be updated with each
successive version of BCP 47 and thus need to be compatible with future
versions of the registry, SHOULD be written so as to ignore additional
fields.
<http://wiki/Main/IIIObjectives>
-- 
Mark
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 1 Jul 2007 16:39:12 -0700

Hi -

As a technical contributor...

> From: "Mark Davis" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Sunday, July 01, 2007 4:18 PM
> Subject: [Ltru] Suggested text for future compatibility of registryprocessors.
....
> versions of the registry, SHOULD be written so as to ignore additional
...

I agree with the intent, but I'd like to propose a slightly different wording:

  Future versions of this memo MAY define additional field types for
  use in the language subtag registry.  Consequently, software to
  process the content of the registry SHOULD tolerate unrecognized
  field types.

Rationales:

(1) I think this is a bit clearer and more concise
(2)  "tolerate" rather than "ignore" - consider the result of
a typo: "Suppers-Script:"   - I think one would like an implementation
to be able to issue a warning, rather than simply ignoring, a field
that it doesn't recognize.

Randy

---

From: "Mark Davis" <[email-masked]>
Date: Sun, 1 Jul 2007 16:55:40 -0700

Your changes sound fine by me. I do have a question. I thought MAY was only
capitalized when it was in reference to conformance to this document. But in
that statement it doesn't seem to apply: it doesn't appear that we in this
document can make any conformance promises (positive or negative) about
future versions since that is entirely in the hands of the IETF.

Mark

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 1 Jul 2007 17:16:15 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: "LTRU Working Group" <[email-masked]>
> Sent: Sunday, July 01, 2007 4:55 PM
> Subject: Re: [Ltru] Suggested text for future compatibility of registryprocessors.
>
...

I was looking at it from a protocol specification perspective.
When defining an extensible protocol, using SHOULD, MUST, etc.
makes sense when specifying the nature of permissible extensions.

If we wanted to be really pedantic, for example, we could spell out that
future extensions MUST NOT violate the syntax established for "record"
in the ABNF.  (If we were indeed going to make a commitment to forward
compatibility in the registry format.  At this point, we haven't constrained
ourselves in this way, and please don't read this example as an argument
that we should constrain ourselves in this way.  Indeed, I think we really
need to discourage implementations (other than very specialized developer
tools) from reading the registry itself, in much the same way as network
management applications don't dynamically query the IANA enterprise number
assignments.)

Randy

---

From: Addison Phillips <[email-masked]>
Date: Fri, 13 Jul 2007 11:59:33 -0700

While catching up on my backlog I notice the following note from Mark.

I would note that we already have a shorter equivalent of this text at 
the end of 3.1.2, where it says:

--
Future versions of this document might add additional fields to the 
registry, so implementations SHOULD ignore fields found in the registry 
that are not defined in this document.
--

This text was apparently added back in draft-02. Any reason to edit it 
some more?

Addison

Mark Davis wrote:
> ------------------------------------------------------------------------
> 

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 13 Jul 2007 12:10:06 -0700

±1

(that is, I'm fine leaving it the way it is, but wouldn't object to
changing either)