On 11/14/14, 1:30 PM, Yutaka OIWA wrote:
Dear PRECIS people,
there seems to be some possible introductions of "sub-profiles" or
"usage-specific alteration to a profile".
It seems to be a generally good way to reduce the numbers of
profiles, but I think we need to clarify some "requirements" for those.
The main factor, to me, is the presence of exclusion rules.
For example, someone in the PCP WG just contacted me and Marc about
advice on i18n. They could use the JIDlocalIdentifierClass from 6122bis,
but they don't have the exclusions that XMPP does (for legacy reasons).
Therefore, as I mentioned during the PRECIS WG session yesterday, I
would be in favor of moving exclusion rules out of profile definitions.
This would enable greater re-use of profiles and help to avoid
multiplying profiles beyond necessity.
In my opinion, an important role of precis profiles is to
make its operation to be a "brack-box" or "library", so that
proper and non-ambiguous handling of Unicode characters are
being done.
Each profiles will be corresponding to one "function" or "instance"
of a brack-boxed library, like a following:
(pseudo-code only: input is "s")
p = Precis.profilehandler("IdentifierClass")
o = p(s);
if (o == null) raise Error;
return o;
Adding some simple preprocess or postprocess to this template is
easy, as far as the process falls into the following form
o = g(p(f(s)))
with simple pre/postprocesses f and g (without deep Unicode knowledge),
For example, disallowing some ASCII special character such as SP
or COLON is quite easy, and good for being a sub-profile.
However, if the process does not fall into this form,
we need to hack into the implementation of Precis Profiles and
it will not be black-boxed anymore.
For example, "adding an allowed character" falls into this class
and it's impossible (in an straight-forward way) with any f and g.
Given the "exclusion model" of PRECIS (following IDNA), I strongly
believe that adding an allowed character needs to be handled as we're
doing it now.
I feel that such "alterations" must be new profiles, or
there will be a lot of buggy, incompatible implementations around the world.
That's why someone needs to make a strong argument for adding allowed
characters.
I also have some concerns on local-mappings: there needs
some reference implementation model for how it will be boxed as a
general library.
Please let me know if you have any opinions or more suggestions.
Thanks for raising this issue.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
