Subject: [xmpp] AD review: draft-ietf-xmpp-address-04

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 03 Oct 2010 09:03:37 +0300

Hi,

I have received a publication request for the following draft:

https://datatracker.ietf.org/doc/draft-ietf-xmpp-address/

Below you can find my AD review.

Cheers,

Gonzalo

Section 1. The last paragraph talks about delays in the revision
process if the address format was specified in 3920bis. Since we are
progressing both drafts together, I do not understand what delays the
text is referring to. I understood the advantage of moving the address
format to a new draft was that such a draft (i.e., this draft) could
be revised at a later point without needing to revise the main spec
again. So, I thought the gains related to modularity, not to reducing
delays.

Section 2.1. I also made this comment on 3920bis. This overview
section contains normative language. I just want to make sure that
was the intention.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Oct 2010 08:34:33 -0600

> again. So, I thought the gains related to modularity, not to reducing

The only reason we care about modularity here is that it might take
several years before the PRECIS WG defines an improved approach to
internationalization of non-DNS addresses (we saw how long it took to
revise IDNA2003), and we didn't want to hold up publication of 3920bis
that long because it contains a *lot* of improvements compared to 3920.

I've adjusted the introduction to draft-ietf-xmpp-address in my working
copy as follows:

###

   As specified in RFC 3920, the XMPP address format re-uses the
   "stringprep" technology for preparation of non-ASCII characters
   [STRINGPREP], including the Nameprep profile for internationalized
   domain names as specified in [NAMEPREP] and [IDNA2003] along with two
   XMPP-specific profiles for the localpart and resourcepart.  However,
   since the publication of RFC 3920, IDNA2003 has been superseded by
   IDNA2008 (see [IDNA-PROTO] and related documents).  As a result,
   other protocols that use stringprep (including XMPP) have begun to
   migrate from stringprep toward more "modern" approaches.

   However, work on improved handling of internationalized addresses is
   currently in progress within the PRECIS Working Group and might take
   several years to complete.  Because all other aspects of revised
   documentation for XMPP have been incorporated into [rfc3920bis], the
   XMPP Working Group decided to split the XMPP address format into a
   separate specification so as not to significantly delay publication
   of improved documentation for XMPP while awaiting the conclusion of
   work on improved handling of internationalized addresses.  This
   specification provides corrected documentation of the XMPP address
   format using the internationalization technologies available in 2004
   (when RFC 3920 was published), with the intent that this
   specification will be superseded as soon as work on a new approach to
   internationalization has been defined by the PRECIS Working Group.

###

Is that clearer?

> section contains normative language. I just want to make sure that

Yes, that is the intention.

Personally I see no reason why a section entitled "Overview" cannot be
normative, but if it's confusing then we could change the title to
something like "Fundamentals".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 05 Oct 2010 11:28:36 +0300

Hi Peter,

thanks for your answers. Regarding the text in the Introduction:

>    the
>    work on improved handling of internationalized addresses.

when I read this I understand that the address format part cannot
published until "the conclusion of work on improved handling of
internationalized addresses". So, we have moved the address format part
to a different spec that will be published later so that the rest of the
XMPP specs can be published sooner. However, that is not the case
because we are publishing the address format at the same time as the
other XMPP specs. So, to me, the advantage of moving the address format
to a different spec is not that it will speed up the publication of the
XMPP specs *now*. The advantage is that when the work on
internationalized addresses finishes, we will only need to revise the
address format RFC, and not the whole XMPP spec.

In any case, this is a minor point. Now that I have clarified my point,
feel free to edit the text as you see fit.

Regarding Overview sections with normative statements, I was referring
to the following document, which recommends not to include them.

http://tools.ietf.org/html/rfc4485#section-4.7

I realize the recommendation, while having a potential general
applicability, is given in the context of SIP extensions :o)

This document references RFC4101, which is mostly about non-normative
protocol overviews:

http://tools.ietf.org/html/rfc4101

In any case, this is a minor style-related point. If you think overview
sections containing normative statements are OK, feel free to not modify
them at all.

Thanks,

Gonzalo

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Oct 2010 06:08:07 -0600

> feel free to edit the text as you see fit.

OK. I still do think there are two factors here, because if waited 2
years (or whatever) to publish the one spec containing the protocol
definitions and the address format then we'd have people implementing to
RFC 3920 (and thus doing some things wrong) instead of 3920bis. It
seemed better to split the address spec out so that we wouldn't wait and
also because then we could revise the address spec independently.

> applicability, is given in the context of SIP extensions :o)

I see. That's similar to the "How It Works" sections in some XMPP
extension protocols (XEPs).

> sections containing normative statements are OK, feel free to not modify

I'll look into changing these in the revised I-Ds coming this week.

Peter

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 5 Oct 2010 23:02:22 +0900

Hi,

I have a related point to the discussion that I was planning to ask
right now as I am reading xmpp-address.
This is in particular about this:

On Mon, Oct 4, 2010 at 11:34 PM, Peter Saint-Andre <[email-masked]> wrote:
[...]
>   migrate from stringprep toward more "modern" approaches.

As you say, IDNA2008 is superseding IDNA 2003. Yet in xmpp-address, we
seem to mainly only deal about IDNA2003 (with just from time to time a
note about IDN2008). I haven't read either of them yet, so maybe there
are not that much difference, but still shouldn't we already move on
to discussing only of IDNA2008 in xmpp-address?
Thanks.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Oct 2010 08:17:04 -0600

> to discussing only of IDNA2008 in xmpp-address?

This is a long story.

Basically, the XMPP WG decided to delay a complete overhaul of the
address definition until we can figure out how to fix the localpart and
the resourcepart, not just the domainpart. The XMPP WG could try to do
this work by itself, but various IETF participants had strong consensus
at the NEWPREP birds of a feather meeting earlier this year to do this
work in a coordinated fashion rather than having each community do this
work for their own technology (SASL, STORM, XMPP, LDAP, etc.) because
(1) those communities might lack the necessary internationalization
expertise and (2) it would be good to have a consistent approach to i18n
issues in the future. This consensus resulted in formation of the PRECIS
WG. Thus people who care about these issues really need to get active in
the PRECIS WG so it can finish its work. Once that is done, we can
replace the temporary draft-ietf-xmpp-address with a permanent solution
(or as permanent as anything can be in the i18n world). That permanent
solution can then be published as a new RFC or it can be folded back
into the core XMPP spec (I prefer the latter approach).

Hope that helps,

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 5 Oct 2010 23:44:17 +0900

Hi,

[...]
> into the core XMPP spec (I prefer the latter approach).

Hum... but if at the end, each protocol/technology does that (folding
back into their own spec), at the beginning, everyone will have the
same spec at first; but with time, this "consistent" approach to
internationalized name might derive in every different spec, hence
become "not so consistent" in the end. I think that's the point of
having a single RFC for all so that each technologies simply have to
reference it (instead of copying it then modifying it).

So oppositely to you, I would prefer the single RFC approach, simply
referenced in xmpp-address (with possible clarification in how we use
this RFC for XMPP sake, but not rewriting it). But we are not here yet
anyway. I guess this might be rediscussed when the consensus will be
done. ;-)

> Hope that helps,

It does, thanks. Still for someone wishing to implement right now
something from this, what would you advise then? Should I focus on
IDNA2003 only for now?
Thanks.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Oct 2010 08:54:30 -0600

> reference it (instead of copying it then modifying it).

I didn't say there would be a single RFC for internationalized strings
in SASL, iSCSI, LDAP, XMPP, etc. The PRECIS WG is trying to define a
common approach or framework that each technology can use by writing
their own specifications. See here:

http://tools.ietf.org/html/draft-blanchet-precis-problem-statement

http://tools.ietf.org/html/draft-blanchet-precis-framework

My input to that thought process was:

http://tools.ietf.org/html/draft-saintandre-xmpp-i18n-01

> anyway. I guess this might be rediscussed when the consensus will be

Indeed it will.

> something from this, what would you advise then? Should I focus on

Are you writing your own IDNA parser? Typically people use libidn.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jehan Pagès <[email-masked]>
Date: Wed, 6 Oct 2010 02:15:43 +0900

Hi,

> http://tools.ietf.org/html/draft-saintandre-xmpp-i18n-01

Ok I see better.

> Are you writing your own IDNA parser? Typically people use libidn.

I don't really know what I am doing exactly. For now I was rather
beginning to study what should be done or not, what exists already,
etc. So yes I'll have a look at libidn then. :-)
Thanks.

Jehan