Subject: [OPS-AREA] FW: Policy MIB stringprep profile

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 16 Feb 2010 11:27:13 +0100

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-masked]] 
Sent: Monday, February 15, 2010 4:35 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: Marc Blanchet; [email-masked]
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:

http://www.ietf.org/mail-archive/web/newprep/current/msg00000.html

See also subsequent discussion on the list:

https://www.ietf.org/mailman/listinfo/newprep

However, we don't necessarily wish to form yet another WG, and one
perfectly acceptable outcome of the BoF would be agreement to pursue any
needed work through independent submissions that update existing work in
this area.

As input to our thinking, would you perhaps have time to post to the
newprep list regarding industry experience with the Policy MIB profile?
We're especially interested in answers to the following questions:

* Approximately what percentage of relevant software has implemented and
deployed the profile?

* How have developers implemented the profile (e.g., by including or
wrapping an existing library such as libidn, or by writing an
independent implementation)?

* Have developers experienced any interoperability issues or other
problems with the profile?

* Might there be developer interest in migrating from the profile to an
approach that is less complex (e.g., by specifying a tiered model of
valid, disallowed, and unassigned characters as in IDNAbis) or more
flexible (e.g., by enabling the use of characters beyond Unicode 3.2 as
fixed by RFC 3454)?

[Alexey and Marc, feel free to modify or add to these questions.]

I plan to post to the newprep list soon regarding the XMPP experience
with stringprep, so perhaps you (or someone else in the network
management community) could take that as a bit of a template.

Any other feedback you might have would be much appreciated.

Thanks for your time.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Jon Saperia <[email-masked]>
Date: Fri, 19 Feb 2010 14:43:48 -0500

Peter,

I am not aware of complete implementations so I do not have anything add.  I suspect some people on this list may have looked at implementation or attempted at least part of it.
/jon
On Feb 16, 2010, at 5:27 AM, Romascanu, Dan (Dan) wrote:

> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 19 Feb 2010 16:01:05 -0800

Hi -

...
> > 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