Re: [MIB-DOCTORS] FW: Policy MIB stringprep profile

Hi -

...
> On Feb 16, 2010, at 5:27 AM, Romascanu, Dan (Dan) wrote:
> 
> > Folks who participated in the Policy MIB work may be interested in this
> > discussion and can possibly help to answer the questions. 
> > 
> > Dan
> > 
> > 
> > -----Original Message-----
> > From: Peter Saint-Andre [mailto:[email protected]] 
> > Sent: Monday, February 15, 2010 4:35 AM
> > To: [email protected]; [email protected];
> > [email protected]
> > Cc: Marc Blanchet; [email protected]
> > Subject: Policy MIB stringprep profile
> > 
> > Gentlemen,
> > 
> > The IETF will hold a BoF at IETF 77 (in Anaheim the week of March 22)
> > about possible replacements for stringprep. I notice that you three
> > authored of one of the few stringprep profiles, for Policy MIB (RFC
> > 4011). Marc Blanchet and I will be co-chairing the BoF, and we're
> > seeking input from authors of all stringprep profiles regarding the
> > possibility of pursuing new approaches to internationalized strings, as
> > has happened already for internationalized domain names through the
> > IDNAbis WG. A proposed charter for a "newprep" working group is here:
...

As far as I can recall, for the Policy MIB the only reason stringprep specifically
was used to describe the desired behaviour  was that that was the preferred
solution at that time, and that "prohibition tables" C.2 through C.9 happened
to cover the things that we could reasonably constrain.  This fits in nicely
with the "exclusion" model, and made coming up with the profile straightforward.
In this particular case, an "inclusion" model would have been more difficult to use,
since the nature of this application put us in the position of wanting to include
everything except a few problematic cases.

This use of stringprep is perhaps a bit different from what was invisioned
by its authors, in that it really isn't about the Policy MIB per se, nor is it
about the protocol.  Rather, its an optional-to-use capability of the
programming language that the user of the MIB has at his/her disposal.
As such, it would perhaps have been more useful (or more over-engineered)
to be able to provide the stringprep profile (or equivalent) as a parameter to
the function, rather than hard-coding the profile in the programming
language's documentation.

Randy