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

On 10/2/14, 10:13 PM, Florian Zeitz wrote:
> On 11.09.2014 03:57, Peter Saint-Andre 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've finally found some time (and remembered) to look over this.

Hi Florian, thanks for the review.

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

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

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

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

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

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

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

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

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

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/