Re: I-D Action: draft-ietf-xmpp-6122bis-13.txt

Hi Jonathan, thank you for the review. Comments inline.

On 9/11/14, 9:04 AM, Jonathan Lennox wrote:
> On Sep 10, 2014, at 9:57 PM, Peter Saint-Andre <[email protected]>
> wrote:
>
>> Changes to address feedback from Joe and Florian.
>>
>> Please review carefully, because some of the changes are subtle or
>> provisional - more feedback would be very helpful.
>
> I think the separation of preparation, enforcement, and comparison is
> very helpful, but I don’t think the description of enforcement is
> very clear yet — it seems to mix together normalization and validity
> checking, without a clear discussion of which rules are which.

I agree that we need to be clearer about what each action includes.

> For example: as far as I can tell, the intention from all discussions
> is that [email protected] is a valid JID, which a server should
> normalize and process as [email protected], but
> “StPeter"@example.com is not, and should be rejected with
> <jid-malformed/>.

I'm not yet sure, but let's think this through.

In essence, we're trying to be nice to client developers by saying that 
you just need to do string preparation (as we've defined it, this means 
for example not transmitting in a localpart slot a string that includes 
Unicode characters outside the PRECIS IdentifierClass). So the strings 
<stpeter> and <StPeter> are acceptable as prepared strings, whereas the 
strings <St Peter> (with a SPACE) and <St—Peter> (with an EM DASH) are 
not. Note that, say, <StPeter's> with an APOSTROPHE is acceptable in a 
prepared string as we have defined it.

What is an enforcing entity supposed to do in these and other cases? 
Section 4.3.2 of 6122bis says that it needs to perform width mapping and 
case mapping and normalization, and that certain characters (e.g., ') 
are excluded/disallowed. So an enforcing entity (typically a server) 
would map <StPeter> to <stpeter>, would reject <St Peter> and 
<St—Peter>, and would very likely reject <StPeter's> (but would we say 
that it could map that to <StPeter\27s> in accordance with XEP-0106 and 
thus be liberal in what it accepts?).

> But I don’t see how you can deduce this from the
> document’s current description of “Enforcement” — both the case
> mapping and the list of invalid characters are specified as “MUST”
> requirements.

And I think that's right.

> The “Preparation” stage also doesn’t seem to require that JIDs that
> are transmitted actually be considered valid by the enforcement
> stage, which seems like a recipe for interop failure.

That might be fine, if the server behaves liberally by mapping whatever 
it can map.

> 6122’s language was "A localpart MUST be formatted such that the
> Nodeprep profile of [STRINGPREP] can be applied without failing” (and
> similarly for the other JID parts).

IIRC some folks considered that to be too weak, which why we now talk 
about enforcement.

> Can language something like this
> (mutis mutandis for Precis rather than Stringprep) be used, once
> Enforcement is clear about what is or isn’t considered failure?

I do think we need to be clear about what is or isn't considered to be 
failure, and specify what an enforcing entity needs to do if it treats a 
string as in violation the rules. My rough guidance would be:

1. If you can map it (by width mapping, case mapping, normalization, or 
JID Escaping), please do so and accept the mapped string. Postel's Law 
in action.

2. If you can't map it (because the character is disallowed by the base 
class definition or an exclusion rule, or because the string violates 
other rules such as length restrictions), refuse the string and return a 
<jid-malformed/> error.

Peter

--
Peter Saint-Andre
https://andyet.com/