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

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 01 Oct 2014 14:53:56 -0700

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-masked]>
> 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-masked] is a valid JID, which a server should
> normalize and process as [email-masked], 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/

---

From: Florian Zeitz <[email-masked]>
Date: Fri, 03 Oct 2014 06:13:45 +0200

> provisional - more feedback would be very helpful.
I've finally found some time (and remembered) to look over this.

I'd like to echo Jonathan Lennox concerns that preparation, enforcement,
and comparison seem a bit under-defined.
In particular enforcement needs some text specifying how invalid JIDs
should be handled by a server.

In section 3 the claim that a server needs to perform preparation in
some cases seems strange to me. From the detailed description in section
5 it always either enforces the rules, or treats the JID as an opaque
part of a c2c protocol.

In section 4.1 it seems a bit unfortunate to say that each code point
needs to conform to a string class. Conformance to such a class is a
property of the string as a whole, due to CONTEXTJ/CONTEXTO.

It is unclear to me how section 4.2.2 is consistent with RFC 5895 as it
claims.
Section 2 of RFC 5895 appears to specify that mappings are performed
before code points are checked for conformance (i.e. step 2 and 3 need
to be performed before step 1 here), and also specifies two more
preparation steps. In general I'm still uncomfortable with trying to
reproduce IDNA2008's algorithms instead of just referencing them.

The text in section 4.4.2 still doesn't seem to address Joe's and my
concerns. Making width and case mappings optional poses an
interoperability hazard. If a sending server performs these mappings,
while the receiving server doesn't, this will yield stanzas that can not
be routed. I would strongly suggest either dropping any text about these
mappings, or making this a MUST NOT.

Regards,
Florian

> Thanks!
> 
> Peter
> 
> On 9/10/14, 7:52 PM, [email-masked] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>   This draft is a work item of the Extensible Messaging and Presence
>> Protocol Working Group of the IETF.
>>
>>          Title           : Extensible Messaging and Presence Protocol
>> (XMPP): Address Format
>>          Author          : Peter Saint-Andre
>>     Filename        : draft-ietf-xmpp-6122bis-13.txt
>>     Pages           : 29
>>     Date            : 2014-09-10
>>
>> Abstract:
>>     This document defines the address format for the Extensible Messaging
>>     and Presence Protocol (XMPP), including support for code points
>>     outside the ASCII range.  This document obsoletes RFC 6122.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-13
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-13
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 10 Oct 2014 10:15:26 -0600

> I've finally found some time (and remembered) to look over this.

Hi Florian, thanks for the review.

> should be handled by a server.

I have some text about this in a working copy, and I plan to publish a 
revised I-D soon (maybe even today or tonight).

> 5 it always either enforces the rules, or treats the JID as an opaque

I'm thinking about things like vCard storage. If I add someone else to 
my vCard, does the server need to perform enforcement or does it treat 
the person's JID as opaque or does it perform preparation? Hmm, I think 
you're right that it wouldn't do preparation only...

> property of the string as a whole, due to CONTEXTJ/CONTEXTO.

That's a very good point. I'll find a way to reword that text.

> reproduce IDNA2008's algorithms instead of just referencing them.

Yes, I think referencing them is better. I will rework that section.

> mappings, or making this a MUST NOT.

OK, I will think about this some more and reply on the list or just 
update the spec with improvements.

Thanks again for the review.

Peter

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