we had a discussion about the same subject: i.e. should we restrict the
scope to a specific set of documents to review/update/... or do we keep
some provision for other documents coming in the stream that require
"help" of the newprep. I was arguing for the latter. To me, what you are
talking about is the latter. Obviously, some people wanted the charter
to be restrictive in order to not go all over the place, and I agree in
principle... However, this work is kinda horizontal: touches many areas,
so having a more large view of the problem space and documents that
depends on this newprep work would be very valuable to the working group
work. Therefore, I'm more for opening a bit the charter for the cases
like the ones you are talking about.
Marc.
Le 10-05-18 13:15, Sam Hartman a écrit :
Hi.
I think there are two items that should be considered with the scope of
this working grou.
The first is RFC 4282. RFC 4282 section 2.4 discusses
internationalization strategies based on stringprep and IDNA2003. It
does not define its own profile. Apparently, in addition to all the
reasons you would probably want to update anything based on IDNA 2003,
RFC 4282 does not meet the needs of the implementor community. One
proposal for addressing RFC 4282 is draft-dekok-radext-nai-01.txt I
think any proposal in this space will require both help from newprep and
from the radext/aaa community. Based on my past experience in emu, the
aaa community, like the rest of the IETF, can use i18n help.
Secondly, I'd like to see Kerberos considered as newprep thinks about
saslprep. Kerberos's formal internationalization is confused and spotty
as a specification level. At the last time that there was active work
on this within krb-wg, the plan was to use saslprep; a prior stringprep
profile was explicitly dropped in favor of saslprep. For this reason, I
think that considering and working with the Kerberos community would be
really useful.
I'm not sure if either of these needs an explicit charter change; I
suspect the first probably does and the second may not. However I think
these both are well within the spirit of the proposed charter.
_______________________________________________
newprep mailing list
newprep@xxxxxxxx
https://www.ietf.org/mailman/listinfo/newprep
--
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf