Subject: [EAI] Erratum? Mixing character-based and byte based ABNF in RFC 6531

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 17 Mar 2012 23:02:15 +0900

While investigating on how to implement a TODO in the updated mailto: 
draft (http://tools.ietf.org/html/draft-duerst-eai-mailto-02.txt), I 
stumbled upon the following in RFC 6531 (Section 3.3, page 8):

       sub-domain     =/   U-label

       atext          =/   UTF8-non-ascii
       (same for qtextSMTP, esmtp-value)

This is highly problematic, because it mixes apples and oranges, or 
characters and bytes, to be precise (see further below for details). In 
other words, it's a layer violation.

While I *hope* that implementers may still get this right, I plan to 
submit an erratum, which does two things:

- Says clearly that the ABNF is in terms of characters (or
   alternatively bytes)

- Fixes one or the other of the definitions to allign the layers.

Before submitting an official erratum, I wanted to check with the WG for 
possible explanations/preferences.

Here are the details: U-label is defined as a string of Unicode 
characters at http://tools.ietf.org/html/rfc5890#section-2.3.2.1:

       A "U-label" is an IDNA-valid string of Unicode characters, in
       Normalization Form C (NFC) and including at least one non-ASCII
       character, expressed in a standard Unicode Encoding Form (such as
       UTF-8).

On the other hand, UTF-8-non-ascii is defined in Section 3.1 of RFC 
6532, as follows:

       UTF-8-non-ascii   =   UTF8-2 / UTF8-3 / UTF8-4

       UTF8-2            =   <Defined in Section 4 of RFC 3629>

       UTF8-3            =   <Defined in Section 4 of RFC 3629>

       UTF8-4            =   <Defined in Section 4 of RFC 3629>

And in Section 4 of RFC 3629, we find:

    UTF8-2      = %xC2-DF UTF8-tail

    UTF8-3      = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
                  %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
    UTF8-4      = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
                  %xF4 %x80-8F 2( UTF8-tail )
    UTF8-tail   = %x80-BF

Which is all in bytes (because that's what an encoding definition is about).

Regards,   Martin.

---

From: "Jiankang Yao" <[email-masked]>
Date: Sat, 17 Mar 2012 22:16:31 +0800

In RFC6531  section
1.1.  Terminology
there is a sentence below

"

   Strings referred to in this document, including ASCII strings, MUST
   be expressed in UTF-8.
"

It  means that U-label must be expressed as UTF-8.

Doe it solve your concern?

Jiankang Yao

----- Original Message ----- 
From: ""Martin J. Dürst"" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 17, 2012 10:02 PM
Subject: [EAI] Erratum? Mixing character-based and byte based ABNF in 
RFC6531

> Here are the details: U-label is defined as a string of Unicode characters 
> at http://tools.ietf.org/html/rfc5890#section-2.3.2.1:
>
> On the other hand, UTF-8-non-ascii is defined in Section 3.1 of RFC 6532, 
> as follows:
>
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Mar 2012 12:47:08 -0400

Martin,

While I think there are a number of things in RFC 6531 that
could be expressed better (I think those who would like to see
an Internet Standard version in September might reasonably start
working on edits now ... although I'd rather see reviews of the
pending set of documents), I'm not sure I see an actual error
here.

Certainly you are correct that U-labels are defined in IDNA as a
list of Unicode code points, independent of encoding.  IDNA
itself is a layer (or half-layer) below anything in any of the
base SMTPUTF8 documents, including RFC 6531.  But the EAI WG
made a very explicit decision that anything that went on the
wire was required to be in UTF-8.  If we were writing prose, it
would be reasonable to express the rule as something like "...
MUST be a U-label and any U-labels used in conformance with this
standard MUST be encoded in UTF-8".  

The best way to express that in ABNF is a separate question.
Personally, I think we are sooner or later going to have to open
RFC 5234 and add some rules to deal smoothly with characters
outside the ASCII range and with the difference between
character-abstractions and particular encodings.  But those are
not problems that 6531 can solve.

I look forward to your erratum, but will push for it to be
classified as "hold for document update".  If Jiankang or others
responded to it by creating a "needs to be revised to clarify
how a collection of i18n issues should be handled" proposed
erratum to 5234, that would be only fitting.

The "mailto:" issue ultimately involves the same abstraction
versus expression/encoding issues that, IMO, are the weak
underbelly of the IRI work.  If you want to adhere to the letter
and spirit of RFC 6531 (and SMTPUTF8 generally), you are stuck
with normalized UTF-8 encoding -- no A-labels and no other
Unicode encoding forms.  If you think that "mailto:" should
represent a different layer of abstraction, e.g., whatever the
IRI abstraction du jour happens to be, then go back to code
points and let RFC 6531 and similar documents impose the
encoding restrictions.

(speaking only for myself, I hope obviously)

   john

--On Saturday, March 17, 2012 23:02 +0900 "\"Martin J. Dürst\""
<[email-masked]> wrote:

> While investigating on how to implement a TODO in the updated
> mailto: draft
> (http://tools.ietf.org/html/draft-duerst-eai-mailto-02.txt), I
> This is highly problematic, because it mixes apples and
> oranges, or characters and bytes, to be precise (see further
> below for details). In other words, it's a layer violation.
> 
> While I *hope* that implementers may still get this right, I
> plan to submit an erratum, which does two things:
> 
> Before submitting an official erratum, I wanted to check with
> the WG for possible explanations/preferences.
> 
> Here are the details: U-label is defined as a string of
> Unicode characters at
> http://tools.ietf.org/html/rfc5890#section-2.3.2.1:
> 
> On the other hand, UTF-8-non-ascii is defined in Section 3.1
> of RFC 6532, as follows:
>

---

From: [email-masked]
Date: Sat, 17 Mar 2012 13:29:09 -0700 (PDT)

> pending set of documents), I'm not sure I see an actual error

Neither do I. While it is nice to talk about layering of ABNF, I see nothing in
this document (or most others, for that matter) that states that any such
layering has been defined and therefore must be respected. You may want that
layering for some purpose of your own in some other document, but the time is
long since past to add such a thing to this revision of this set of documents.
And even if this is the only place that needs to change in order to make the
layering work (unlikely), it's completely inappropriate to attempt to add what
amounts to a new feature in an erratum.

The only possible issue I see is that the u-label definition allows any sort of
encoding of the actual characters. Frankly, I'd call that a bug in the
definition of u-label itself since IMO ABNF should always resolve down to the
actual sequence of octets, but as John notes below, this specification
repeatedly states that utf-8 is the only encoding we're using, so there's no
strong need to restate it here.

> not problems that 6531 can solve.

Agreed.

> erratum to 5234, that would be only fitting.

I'm sorry, but I'm not as accepting as this - I don't think an erratum of the
sort you appear to be proposing should be accepted, period. The last thing we
need is to attempt to put in an ABNF layering in an implicit and therefore
half-assed way. What happens if some later change gets made and breaks the
layering because nobody is paying attention to preserving it?

If want to define a layering, it needs to be done explicitly and carefuly, and
once added the entire document set needs to be reviewed to make sure we've done
it consistently. (The WG will also have to agree to do it, of course.)

I'll also note that RFC 6532 was written in a fashion to avoid this stuff
entirely, and I'll push back hard on any attempt to add it there since I think
it will only add unnecessary complexity to what has become, after considerable
effort, a surprisingly simple document. More specifically, since the allowed
characters in domain names resolve down to atext through atoms and atoms are
allowed in lots of other contexts in header fields, attempting to impose
u-label normalization restrictions or whatever on RFC 6532 domain names
instantly buys us into the old ABNF approach that was soundly rejected as being
much to complex to deal with. And besides, domains as defined in RFC 5322
already allow all sorts of characters that the DNS doesn't, so this is hardly a
break with how things have been done previously.

In fact one of the main differences between RFC 5322 and RFC 822 is the
rejection of ABNF layering approach. I'm personally not entirely comfortable
with that, mostly because I believe using a layered parsing approach simplifies
implementation considerably, but there's no doubt the way it was done in RFC
822 was quite sloppy and it isn't clear to me that just trying to clean up that
sloppiness would have resulted in a cleaner or simpler specification. (Of
course this is entirely academic now - we're not going to change approaches at
this point, just as we're not going to split productions apart in RFC 5322 to
make RFC 6532's life easier.)

Now, if you want to propose a very simple erratum that clarifies that the use
of u-label uses the utf-8 encoding, I'm not really sure it's necessary but I
will support doing that.

> points and let RFC 6531 and similar documents impose the

Exactly. While it is always nice if a given specification is done in a way that
makes it easier to write other specifications, it is in no way incumbent on
them that they do so. And in this particular case the issue should have been
raised well over a year ago.

I'll also add that my sympathy level is low to nonexistent because this happens
to all of us all the time, and most of us have learned to suck it up and move
on. The lack of separate productions for some things RFC 5322 is a case in
point - having those would have made RFC 6532 much easier to write, but you
didn't hear us asking to reopen RFC 5322.

In fact entire standards efforts, including some that involved a huge amount of
time and effort, have been consigned to the dustbin in part because of a
failure to pay attention to  the details of comtemporaneous standards
development. The obvious example here is PEM - had PEM paid attention to MIME
it might possibly have made the development of S/MIME unnecessary. But it
didn't, and the rest is history.

There are also times where you get lucky, like when MARF wanted to remove some
restrictions on multipart/report. It happened at a time when the DSN document
suite was being revised anyway and the change actually fixed an issue in DSN
usage while not being overly onerous to make, so  in the end everything worked
out. But you cannot count on this happening, although it's nice when it does.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Mar 2012 18:32:59 -0400

--On Saturday, March 17, 2012 1:29 PM -0700 Ned Freed 
<[email-masked]> wrote:

>...
>> classified as "hold for document update".  If Jiankang or
>> others responded to it by creating a "needs to be revised to
>> clarify how a collection of i18n issues should be handled"
>> proposed erratum to 5234, that would be only fitting.
>
> I'm sorry, but I'm not as accepting as this - I don't think an
> erratum of the sort you appear to be proposing should be
> accepted, period. The last thing we need is to attempt to put
> in an ABNF layering in an implicit and therefore half-assed
> way. What happens if some later change gets made and breaks the
>...

Ned, no real disagreement.  I wouldn't mind having a placeholder 
that essentially says "next time these documents are opened, 
review this".  I think there ought to be better ways to do that 
than with the errata files but, since we aren't keeping an 
issues tracker for published documents (and such a tracker would 
be pretty likely to get lost when we suspend or close the WG 
anyway), that may be the best we have (and fixing _that_ problem 
is definitely not something that is under EAI control).

The result of looking at it might well be a conclusion that 
nothing else needs to be done or that some additional "only 
U-labels encoded in UTF-8" sentences are needed.   I doubt that 
it would result in a conclusion that the ABNF needed to be 
changed unless some i18n changes had been made to ABNF first, 
but Martin could make a case for that at that time.   I 
certainly did not mean to imply that changes to the ABNF were a 
foregone conclusion.

>...
> I'll also note that RFC 6532 was written in a fashion to avoid
> this stuff entirely, and I'll push back hard on any attempt to
> add it there since I think it will only add unnecessary
> complexity to what has become, after considerable effort, a
> surprisingly simple document. More specifically, since the
> allowed characters in domain names resolve down to atext
> through atoms and atoms are allowed in lots of other contexts
> in header fields, attempting to impose u-label normalization
> restrictions or whatever on RFC 6532 domain names instantly
> buys us into the old ABNF approach that was soundly rejected
> as being much to complex to deal with. And besides, domains as
> defined in RFC 5322 already allow all sorts of characters that
> the DNS doesn't, so this is hardly a break with how things
> have been done previously.

You could add that the "UTF-8 on the wire" restriction doesn't 
necessarily apply to the relationships between mail header 
fields and mail reading (POP, IMAP, Web, local, ...) software on 
a single system and that trying to cover the specific cases 
there would not only break many precedents but would be 
generally insane (or perhaps just a cause of insanity).

>...
> Now, if you want to propose a very simple erratum that
> clarifies that the use of u-label uses the utf-8 encoding, I'm
> not really sure it's necessary but I will support doing that.

See above.

>> underbelly of the IRI work.  If you want to adhere to the
>> letter and spirit of RFC 6531 (and SMTPUTF8 generally), you
>> are stuck with normalized UTF-8 encoding -- no A-labels and
>> no other Unicode encoding forms.  If you think that "mailto:"
>> should represent a different layer of abstraction, e.g.,
>> whatever the IRI abstraction du jour happens to be, then go
>> back to code points and let RFC 6531 and similar documents
>> impose the encoding restrictions.
>
> Exactly. While it is always nice if a given specification is
> done in a way that makes it easier to write other
> specifications, it is in no way incumbent on them that they do
> so. And in this particular case the issue should have been
>...

> There are also times where you get lucky, like when MARF
> wanted to remove some restrictions on multipart/report. It
> happened at a time when the DSN document suite was being
> revised anyway and the change actually fixed an issue in DSN
> usage while not being overly onerous to make, so  in the end
> everything worked out. But you cannot count on this happening,
> although it's nice when it does.

Of course, our diddling a bit with RFC 4409 message submission 
to explicitly permit remapping addresses in RFC 6409 in order to 
prevent an ugly situation in EAI is another example and one that 
is a bit closer to home.  In a situation somewhat similar to the 
DSN one, YAM already had 4409 open; the EAI requirement 
certainly contributed to Randy and my getting motivated.

I agree with your other comments as well.

    john

---

From: [email-masked]
Date: Sat, 17 Mar 2012 15:35:36 -0700 (PDT)

> certainly did not mean to imply that changes to the ABNF were a

Placeholders are fine as long as there's no expectation that having
accepted the erratum that something _will_ be done.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Mar 2012 20:13:38 -0400

--On Saturday, March 17, 2012 3:35 PM -0700 Ned Freed 
<[email-masked]> wrote:

>> U-labels encoded in UTF-8" sentences are needed.   I doubt
>> that it would result in a conclusion that the ABNF needed to
>> be changed unless some i18n changes had been made to ABNF
>> first, but Martin could make a case for that at that time.   I
>> certainly did not mean to imply that changes to the ABNF were
>> a foregone conclusion.
>

Something will be done.  We will be sure to look at the 
question.  If the answer turns out to be something similar to 
what you and I have been discussing, that will be the end of 
it... at least within my ability to affect things.   But I agree 
with your implicit suggestion that any "hold for document 
revision" status should go in with an explicit comment that 
briefly summarizes this discussion and points back to the 
mailing list entries.

   john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 19 Mar 2012 20:39:17 +0900

Hello John,

Many thanks to you and others for your comments.

On 2012/03/18 1:47, John C Klensin wrote:
> pending set of documents),

These will be forthcomming, hopefully this week. I started with RFC 
6530/1/2 because I hadn't looked at the base specs in a while and 
because I needed to look at them anyway for the mailto: spec (which, 
among many other things, actually is on the WG's charter).

> I'm not sure I see an actual error
> here.
>

Yes, indeed.

> The best way to express that in ABNF is a separate question.

My understanding so far is that the main purpose of ABNF is direct or 
indirect executability. Although ABNF can express context-free 
languages, in the bulk of uses in the IETF, there is no recursion among 
rules, and in these cases, conversion to regular expressions is often 
done. There lots of regular expression engines running on bytes, and 
there are many (sometimes the same ones) running on (Unicode or 
otherwise) characters, but I don't know of one where you could do both 
things at the same time. Maybe you do?

> not problems that 6531 can solve.

No need to worry. These problems are *already solved* at
http://tools.ietf.org/html/rfc5234#section-2.3:

2.3.  Terminal Values

    Rules resolve into a string of terminal values, sometimes called
    characters.  In ABNF, a character is merely a non-negative integer.
    In certain contexts, a specific mapping (encoding) of values into a
    character set (such as ASCII) will be specified.

(Also check out http://tools.ietf.org/html/rfc5234#section-2.4, but 
please note that this is about how ABNFs themselves are encoded, not 
about what they describe.)

While we are at it, please also note that the word "octet" appears only 
two times in RFC 5234, as opposed to about 25 mentions of "character".

Also, please note that this is not only theory, it has already been 
used, in http://tools.ietf.org/html/rfc3987#section-2.2, after due 
explanation:

                                     Character numbers are taken from the
    UCS, without implying any actual binary encoding.  Terminals in the
    ABNF are characters, not bytes.

    ucschar        = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
                   / %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
                   / %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
                   / %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
                   / %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
                   / %xD0000-DFFFD / %xE1000-EFFFD

    iprivate       = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD

Some ABNF checkers barked on some parts of the ABNF used there, but that 
was the checker's fault, not the ABNF's.

> classified as "hold for document update".

That would be fine by me.

> If Jiankang or others

No, it wouldn't, because there is no need to fix 5234.

> underbelly of the IRI work.

I agree that insofar as "mailto:" is an URI/IRI scheme, it will share 
encoding "issues" with IRIs in general. That should come as no surprise.

However, I have to clearly and strongly disagree with (casual or 
on-purpose) interjections such as "weak underbelly". I hope we can all 
avoid such terms in technical discussion.

> If you want to adhere to the letter
> Unicode encoding forms.

I would expect that not only I, but also everybody else, will adhere to 
the letter and spirit of RFC 6531, which says that *in the SMTP 
protocol*, it's UTF-8 and UTF-8 only. Same for RFC 6532 and header 
fields *in transit*.

However, in good IETF tradition, I'd expect that implementations of all 
kinds (MUAs, MTAs,...) have all the liberty they need to choose other 
encodings where that makes sense for them, as long as they respect the 
RFCs on the wire. I may even have seen wording to that effect in one or 
the other (or both) of the above RFCs, but I assumed that as a matter of 
course and so didn't pay enough attention to be sure about it. As just 
one concrete example, I would assume that an MUA written in Java would 
use UTF-16 to store email addresses in memory.

> If you think that "mailto:" should
> represent a different layer of abstraction,

It's not that *I* think, it's that because the "mailto:" scheme is an 
URI/IRI scheme, it has to work like an URI/IRI scheme.

Please note that this isn't just an IRI issue, the issue is present in 
URIs, too. Please see the first paragraph of 
http://tools.ietf.org/html/rfc3986#section-2. For an actual example, 
please think about an URI embedded in an EBCDIC-encoded text (for those 
not old enough to remember EBCDIC, please try with UTF-16).

> e.g., whatever the
> IRI abstraction du jour happens to be,

I'm in danger of repeating myself, but I have to clearly and strongly 
disagree with (casual or on-purpose) interjections such as "abstraction 
du jour". I hope we can all avoid such terms in technical discussion.

[To give everybody some background, the design alternatives listed in 
http://tools.ietf.org/html/rfc3987#appendix-A represent the state of 
circa 1995, and around that time included the current solution (which of 
course doesn't have to be listed in that appendix). As early as 1996 
(mainly motivated by 
http://tools.ietf.org/html/draft-weider-iab-char-wrkshop-00), it was 
clear that the current solution was the right one. That's roughly 16 
years ago.]

> then go back to code

To get back to my main original point: It's of course clear to me that 
it's RFC 6531 and friends that have to impose the encoding restrictions, 
because otherwise implementations are overly constrained and humans 
(mail addresses have to work on paper and soundwaves, too) can't use 
these things.

But this is orthogonal to the question of whether the ABNF in RFC 6531 
should be written in terms of octets or in terms of (Unicode) code 
points. Either one is fine with me, but that still doesn't mean that 
mixing is a good idea.

Having thought about the text in RFC 6531 a bit more, and looked at 
http://tools.ietf.org/html/rfc5890#section-2.3.2.1 again, I actually 
think it's not even so much a problem of mixing two levels of 
description (characters and octets) as of trying to import an ABNF rule 
when there never was one. Here is what 
http://tools.ietf.org/html/rfc6531#section-3.3 says:

    The following ABNF rule will be imported from RFC 5234, Appendix B.1,
    directly:

    o  <DQUOTE>

    The following ABNF rule will be imported from RFC 5890, Section
    2.3.2.1, directly:

    o  <U-label>

If I go to http://tools.ietf.org/html/rfc5234#appendix-B.1, I indeed find:

          DQUOTE         =  %x22
                                 ; " (Double Quote)

(which I can add directly to the grammar if my ABNF infrastructure 
hasn't it predefined already). On the other hand, if I got to 
http://tools.ietf.org/html/rfc5890#section-2.3.2.1, I see some very 
precisely worked out definitions that I should be able to turn into 
whatever I need for my implementation in due time if I'm not lucky 
enough to find a library that has already done that. However, (and 
actually for good reasons,) even the word "ABNF" is nowhere in sight in 
RFC 5890.

So I currently think that I will propose an erratum along the following 
lines:

In http://tools.ietf.org/html/rfc6531#section-3.3, replace

<<<<
    The following ABNF rule will be imported from RFC 5890, Section
    2.3.2.1, directly:

    o  <U-label>

    The following rules are extended in ABNF [RFC5234] as follows.

    sub-domain   =/  U-label
     ; extend the definition of sub-domain in RFC 5321, Section 4.1.2
<<<<

by

    The following rules are extended in ABNF [RFC5234] as follows.

    sub-domain   =/  <U-label as defined in RFC 5890, encoded in UTF-8>
     ; extend the definition of sub-domain in RFC 5321, Section 4.1.2

There are a few other places where RFC 5890 is mentioned in RFC 6531, 
and which may have to be tweaked, too.

Regards,    Martin.

---

From: [email-masked]
Date: Thu, 22 Mar 2012 08:50:40 -0700 (PDT)

> indirect executability.

That's incorrect. The main purpose of ABNF is to provide a precise
specification of the syntax that's allowed by a given specification. The choice
of rules often also ties into the semantics.  Executability is at *best* a
tertiary goal. That's why we allow terminals to be defined in prose, allow
complex additional constraints to be expressed in comments, and place no limits
on the use of recursion.

> Although ABNF can express context-free
> done.

And lots of problems result from that rather foolish design pattern. It is
rarely the best implementation choice, and the fact that it's popular in some
circles doesn't change things any.

Parsing email headers is a case in point. There are at least two well known
rants about how badly designed modern email is, both from well known members of
the Perl community. But as is often the case with such things, they reveal more
about the biases of the ranter than they do about the subject being ranted
upon. And in this case they both mostly boil down to "Waah! This stuff is hard
to deal with using regexps!", since of course that's Perl's hammer. What they
really end up saying, in effect, is that these are people unwilling or unable
to look past their hammer of choice to look at alternative approaches that
solve the problem quite easily.

> There lots of regular expression engines running on bytes, and

The present situation is another case in point for why you shouldn't be trying
to convert ABNF to regexps willy-nilly. The real question you should be asking
is whether or not you can usefully do IDNA constraint checks in a regexp,
because if you're going to perform an actual syntax check at this level that's
what's required.

> That would be fine by me.

It's going to depend on what the erratum says. If it's a simple patch to
clarify the issue of needing to specify utf-8 as the encoding for u-labels,
I've already said that's fine and in fact it should be approved immediately and
not held for a document revision.

If it attempts to go further and some layer concept to these documents, then
it's going to depend on whether that's stated as a possible solution to a
problem or a requirement that it must be done. The former is acceptable
(although it should be held for a document revision), the latter is not.

> use UTF-16 to store email addresses in memory.

That's yet another hammer that causes implementation problems in practice
(usually ones relating to field length limit calculations).

> actually for good reasons,) even the word "ABNF" is nowhere in sight in

But this also suggest that the right way to address the issue is to simply
define a new ABNF rule:

    u-label = <string of characters encoded in utf-8 conforming to the
               u-label constraints given in RFC 5890 section 2.3.2.1>

>      ; extend the definition of sub-domain in RFC 5321, Section 4.1.2

I think defining a u-label rule is a little cleaner, but this is acceptable.

> and which may have to be tweaked, too.

Again, it's going to depend on what those tweaks end up saying.

				Ned