On 3/10/15 6:51 PM, Ben Campbell wrote:
On 10 Mar 2015, at 18:13, Peter Saint-Andre - &yet wrote:
On 3/10/15 4:38 PM, Ben Campbell wrote:
BTW, I reviewed version 19, quite by accident :-)
On 10 Mar 2015, at 17:30, Ben Campbell wrote:
(as individual)
Hi,
This is a very well written draft. It's easy to understand given the
complexity of the material. I support it's publication.
I have a few minor comments:
-- section 3.2, paragraph 6:
Is there a reason to avoid a reference for IDNA2008?
Well, IDNA2008 is collectively RFCs 5890-5894 and we do point to
several of those specs in ยง3.2. :-)
I guess I should have said "... here", but needing 5 references probably
argues against doing it again. :-) It just sort of looked strange that
it was missing while the next phrase had a reference.
-- 3.3, implementation note:
Are there any practical consequences for the implementor? Are there
potential conflicts where the XMPP implementation correctly forms a
Localpart, but it contains an identifier that is interpreted
incorrectly by some SASL mechanism?
Re-using the UsernameCaseMapped profile from
draft-ietf-precis-saslprepbis should help in this regard. However, as
noted, some SASL mechanisms might not be upgraded quickly and thus
would still use SASLprep (RFC 4013). The differences are explained a
bit more in Appendix A of draft-ietf-precis-saslprepbis - as I see it,
the only semi-major issue is that certain characters that were "mapped
to nothing" in RFC 4013 are simply disallowed by the
UsernameCaseMapped profile that we re-use in 6122bis.
So an identifier created with UsernameCaseMapped should be fine, but an
identifier created somewhere else in sasl might not be legal? That
_seems_ unlikely to be a problem...
Right.
It might not hurt to mention the saslprepbis appendix in the note.
Actually, Section 6.1 of draft-ietf-precis-saslprepbis is an even better
pointer because it describes the differences in more detail, with an eye
toward migration from Stringprep to PRECIS. You might want to re-read
that section to determine the level of your concern.
-- 3.3.1, implementation note:
I have mixed feelings about XEP-0106 being an informational reference
(using the standard of "need to read to understand/implement this
document"). Even if an implementation chooses not to create JIDs with
escaped characters, it had to be prepared to receive them from
somewhere else, doesn't it?
Well, the alternative is to reject the JID - but since the escaping
mechanism in XEP-0106 is really a matter of presentation, it's
something that affects clients more than servers anyway (and the JID
escaping would be applied before PRECIS-related processing happens
anyway).
So a server would just operate on the escaped string without worrying
about the fact. Got it. OTOH, this draft applies to clients, too. I
suppose a client might display the raw string without unescaping, but
that would be ugly.
Yes, but it's interoperably ugly! ;-)
OTOH, that goes beyond the point of _this_ draft, so I'm okay leaving it
as informational.
[...]
-- 8:
While I don't object to the approach of the section, I think there's
some risk of confusion about which text is authoritative from a 2119
perspective. I think it might be worth noting that the authoritative
text is in the referenced sections, and only summarized here for
convenience. (It only really matters if they conflict, but redundant
normative text makes life harder for future updates.)
I see your point: it's never a great idea to say the same thing in two
places.
We do say:
This section describes a protocol feature set that summarizes the
conformance requirements of this specification....
We could add a sentence like:
The summary is purely informational and does not override any of the
more detailed descriptions in the body of this specification.
How about adding something more specific. For example, something to the
effect of the following (to either the current text or with your
proposed addition):
"[RFC2119] keywords in this section are intended to describe the
referenced normative text."
(A careful reader will figure out the right thing without it. But I'm
not worried about _careful_ readers ;-) )
WFM!
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
