Re: WGLC of draft-ietf-xmpp-6122bis-11
Peter Saint-Andre <[email protected]>
| Newsgroups | gmane.ietf.xmpp |
|---|---|
| Message-ID | <[email protected]> |
On 3/25/14, 1:58 PM, Matt Miller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> I've finished reviewing draft-ietf-xmpp-6122bis-11. I mostly think
> this document is ready to be published. I think it deals with the
> internationalization issues at hand as well as can be expected.
>
> However, in 3.2. Domainpart, I wonder about the following:
>
> 4. So-called "additional mappings" MAY be applied to the domainpart,
> such as those defined in [I-D.ietf-precis-mappings] or [RFC5895].
>
> As far as I can tell, just about all of the suggested mappings from
> RFC5895 are already required here. But for any that are not, I worry
> about the potential for interoperability problems if say two servers
> communicating with each other apply different mappings. It might be
> best to strike this bullet from the list.
Yes, I think you are right that it would be best to remove this step.
While updating draft-ietf-precis-saslprepbis last night, I removed any
mention of additional mappings from the password algorithm, for similar
reasons.
> Less concerning to me is in 3.3. Localpart:
>
> 2. So-called "additional mappings" MAY be applied, such as those
> defined in [I-D.ietf-precis-mappings].
>
> I think there is less concern about interoperability problems here,
> but I wonder if it is of any real utility.
In saslprepbis, we've changed the username text to read:
3. So-called additional mappings MAY be applied, such as mapping of
delimiters (e.g., characters such as '@', ':', '/', '+', and '-')
and special handling of certain characters or classes of
characters (e.g., mapping of non-ASCII spaces to ASCII space or
mapping of control characters to nothing); the PRECIS mappings
document [I-D.ietf-precis-mappings] describes such mappings in
more detail.
However, that kind of mapping doesn't apply to XMPP localparts because
we profile the PRECIS IdentifierClass, which prohibits punctuation and
space characters outside the ASCII7 range, control characters, etc. So
IMHO it's unnecessary for localparts.
> The similar language in 3.4. Resourcepart is not concerning to me at
> all; there are some cases where additional mappings are desirable
> (e.g., MUC nicknames), and I think the language makes it clear that
> anything beyond "it's opaque" is to be approached with care.
Agreed, although I'd change the bullet to mostly or entirely match what
I added to draft-ietf-precis-saslprepbis.
Peter