Subject: [nfsv4] Going forward on I18N in RFC3530 bis

From: <[email-masked]>
Date: Thu, 9 Sep 2010 18:35:57 -0400

David Black (the man behind NFSv4.2 :-) has asked me to summarize the
situation with regard to I18N in RFC3530 and the current plan about what
to do about it going forward in handling it in RFC3530bis.

---- First some pointers:

    The description of I18N is in chapter 11 of RFC3530, 
    page 122 of http://www.ietf.org/rfc/rfc3530.txt 

    The current draft replacement is in the latest draft
    of RFC3530bis, that is, in chapter 12 (pages 160-179)
    http://tools.ietf.org/id/draft-ietf-nfsv4-rfc3530bis-04.txt.
    This is pretty much a rewrite of chapter 12 of the 
    previous draft-03, so looking at the diff is not much help.

---- Background:

The basic problem with chapter 11 of RFC3530 is that it has almost no
relation to what has been actually implemented.  The current form of
chapter 11 reflects political pressures at the time of RFC approval
within the IETF to conform to the stringprep paradigm, and so it is
organized around that.  But implementations started without it, and
never were adjusted to conform to that model, for good reasons,
discussed below.

In the meantime, problems within stringprep have become manifest.  Even
more important is the fact that for the most important string type
subject to I18N issues, filename components, the stringprep-style
approach in its totality does not match the needs of NFSv4.  The issue
is that you can think of the server as a single thing (including the
server code and the file system you are talking to) in which case it
makes sense to define, in exquisite detail, character mapping, and
repertoire rules, so as to provide interoperability down to the most
recondite character-handling details.  

However in fact, server implementations and file-systems are separate
things and one cannot enforce detailed character handling rules on the
file-systems and if one does one limits unacceptably the file systems
that one can use.  And if one does that in front of the file systems, we
interfere with another major goal of NFSv4, proper interoperability with
other network file systems and with local use of those file systems.  If
the protocol imposes rules that are not imposed locally, there may be
valid files you can't get at over NFSv4.

As a result, NFSv4, at least in this regard is better described as a
protocol to pass names from the client to the remote server file system,
making as few modifications as we can.  In fact, this is what people
actually implemented and it differs in a major way from what is
described in chapter 11 of RFC3530.  Thus the need to describe the
reality that clients and servers implement in RFC3530bis.

---- Changes:

This is a brief summary of the changes I introduced.  It is a high-level
summary and I may have forgotten a few things.

Re-organize the string types.  In RFC3530, these had been organized
about stringprep profiles, basically around whether strings
case-sensitive or not, or partially case-sensitive.  The resulted in
very strange conclusions such as applying UTF-8 checking and checking
for characters outside Unicode 3.1 being applied to tags.

Tags are treated opaquely with no UTF-8 checking, Unicode repertoire
checking, normalization-related checking.

There is more clarity about various sorts of strings.  In particular,
string which, for various reasons, do not require internationalization
handling are explicitly called out.

Adopting IDNA handling for domains and servers and simply referencing
those docs for what is OK.  There is the issue of U-labels vs. A-labels.
We allow A-labels or UTF-8 strings whether canonicalized or not.  There
has been some discussion about changing that to U-labels only but that
will only be done if there is working group consensus.

Extensive discussion of the fact that our ability to legislate character
handling for file systems is limited.

Change UTF-8 requirement for filenames from MUST to SHOULD to match
NFSv4.1.

Get rid of requirement that everything be within Unicode 3.1.  Get rid
of requirements that large sets of characters within Unicode 3.1 be
rejected for various reasons. 

Get rid of requirement to map various characters.  SHOULD NOT do
mappings which are problematic for stringprep (German eszett mapped to
'ss', zero-length join and non-join characters mapped to nothing causing
issues Farsi) but MAY use other mappings in that (and by implication no
mappings outside it).

New treatment of normalization.  Allow normalization-sensitive servers
(but warn of difficulties without saying SHOULD NOT), allow
servers/file-systems to choose to normalize NFC or NFD (but not reject
filename in "wrong" normalization as was implied by RFC3530), and also
mention/allow for the first time
normalization/insensitive/normalization-preserving handling of names
(best choice but no SHOULD because this is big change to the file system
ad thus nor really spec's business).

Discussion of how symlink text should be processed and where the
handling differs from file component names.

New treatment of user/group names.  Each domain establishes its own list
of these so there are no repertoire rules.  There is a discussion about
why you should match these based on canonical equivalence, but there is
no n/i-n/p option for these because it would require fs to save 2 (or
sometimes many more) variants of that same user and group in the user
and group attributes and in ACLs.   Nobody is going to do that nor
should they.

I'm sure I've missed some things.  If you notice them, let me know, as
it would be good to maintain somewhere a summary of what was done in
this chapter.

---- Discussion on call:

The big issue discussed was whether we should wait for precis to finish
this up.

David Black came to the conclusion that since precis work was not
proceeding very fast, we should go ahead based on the current draft plus
working group comments, with the potential of an additional update
(RFC3530tris?) when the precis work is finished and can be applied to
NFSv4.

There were arguments about his use of the word "patch" and the probable
relative proportions of updates in RFC3530bis and its successor but no
fundamental disagreement on the basic approach.

I will be working on an update to chapter 12 that will go into a new
draft of rfc3530-bis, targeted at the Beijing deadline.  May be able to
get it out earlier but I hope people will have chance to look at the
current draft and give me their comments.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 09 Sep 2010 21:38:34 -0400

> current draft and give me their comments.

The other point that I heard being made (and for which we appeared to
have consensus) was that in the short term, we should attempt to
document existing practice (as Dave has indeed been doing). IOW:
existing NFS implementations and best practices should be the guideline
for 3530bis while we wait for the IETF High Lords of
Internationalisation to agree on basic procedure...

Cheers
  Trond

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 10 Sep 2010 07:33:00 -0700

>> (RFC3530tris?) when the precis work is finished and can be applied to

I was a bit more quiet on this point than I should have been - I think we should
be trying to avoid a 3530tris unless we can make sure that the delta is pretty
small. We will not be winning friends with the ADs with huge changes.

If the i18n chapter is the same for 3530, 5661, and whatever comes next,
perhaps it should be a separate document.

I was okay pulling the ACL and Multi-Server Namespace chapters back from
5661 because in essence we were saying that implementation experience
has shown us what we should have originally put down and we know there
won't be wholesale changes in these areas again. I.e., fs_locations_info is
already in place and will not be backported.

But the i18n seems ripe for a lot of churn.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: <[email-masked]>
Date: Fri, 10 Sep 2010 15:00:40 -0400

> I was a bit more quiet on this point than I should 
> have been - I think we should be trying to avoid a 
> 3530tris unless we can make sure that the delta is 
> pretty small. 

It's interesting how attitudes can differ.  I think Tom and I have
similar attitudes towards RFC3530tris but neither said much.  Tom
regrets he didn't say more while I was patting myself on the back for
the restraint I showed.

I think the point is that despite the validity of Tom's position, there
isn't much we can do at this point.  There is some speculative set of
changes that precis might make desirable but it might be the null set.
There no way to tell and speculation is a waste of time.  We should do
what we can do now and leave what we can't do now to the future.

> We will not be winning friends with 
> the ADs with huge changes.

Granted but if they are required then we will make them.  We have to
decide whether the goal is making friends or properly specifying the
protocol.  If I was concerned with winning friends with the AD's, I
would have left the internationalization chapter pretty much as it was,
pretend that everything was OK, and have some more free time.  So I
realize I made a bad decision but that's life :-)

> If the i18n chapter is the same for 3530, 5661, and 
> whatever comes next, perhaps it should be a separate 
> document.

Perhaps, but I'd rather we didn't try to make that decision now and
complicate the process.  I believe that as we think about going to
group-last-call for RFC3530-bis, we should decide on whether we want to
split out the internationalization as a separate document that applies
to multiple minor versions.  If we decide to do that, it can be done is
a day or less.

And I really hope Tom is wrong about I18N churn.  We'll see.

-----Original Message-----
From: Thomas Haynes [mailto:[email-masked]] 
Sent: Friday, September 10, 2010 10:33 AM
To: Trond Myklebust
Cc: Noveck, David; [email-masked]
Subject: Re: [nfsv4] Going forward on I18N in RFC3530 bis

>> (RFC3530tris?) when the precis work is finished and can be applied to

I was a bit more quiet on this point than I should have been - I think
we should
be trying to avoid a 3530tris unless we can make sure that the delta is
pretty
small. We will not be winning friends with the ADs with huge changes.

won't be wholesale changes in these areas again. I.e., fs_locations_info
is

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 10 Sep 2010 19:31:23 +0000

Before getting excited about document separation, let's work through
the review of the details and use that as a means to determine the
best method of document management.

As an aside: The clear goal for rfc35030bis is to fix the bugs with respect to
successful implementation from the text.  Is there any desire from the
WG to consider the document update as attempt to move the
protocol beyond proposed standard or is the sense that it is still
too early or not within the energy envelope of the WG?

Spencer

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Thomas Haynes
> Sent: Friday, September 10, 2010 7:33 AM
> To: Trond Myklebust
> Cc: [email-masked]
> >> situation with regard to I18N in RFC3530 and the current plan about
> >> what to do about it going forward in handling it in RFC3530bis.
> >> ---- Discussion on call:
> >>
> >> The big issue discussed was whether we should wait for precis to
> >> finish this up.
> >>
> >> proceeding very fast, we should go ahead based on the current draft
> >> plus working group comments, with the potential of an additional
> >> update
> I was a bit more quiet on this point than I should have been - I think we
> should be trying to avoid a 3530tris unless we can make sure that the delta is
> pretty small. We will not be winning friends with the ADs with huge changes.
> 
> >> There were arguments about his use of the word "patch" and the
> >> probable relative proportions of updates in RFC3530bis and its
> >> successor but no fundamental disagreement on the basic approach.
> >>
> >> draft of rfc3530-bis, targeted at the Beijing deadline.  May be able
> >> to get it out earlier but I hope people will have chance to look at
> >> the current draft and give me their comments.
> >
> > existing NFS implementations and best practices should be the
> > guideline for 3530bis while we wait for the IETF High Lords of

---

From: <[email-masked]>
Date: Wed, 22 Sep 2010 11:48:44 -0400

Dave,

I reviewed the i18n material in -04 (Section 12).  it looks fairly good, but the details are now beyond my level of i18n expertise.  I suggest that we get a real i18n expert to review this section in the next version of the draft - I have a couple of candidate reviewers in mind.  Many thanks for the extensive effort that has clearly gone into this.

I have one basic disagreement that should not come as a surprise ;-) ...

My current view of A-labels vs. U-labels is that I'm going to (try to) insist on no A-labels, *unless* there is important "running code" that depends on A-labels on the wire and that needs to be grandfathered.  A-labels exist because the DNS infrastructure is fundamentally ASCII.  Since NFSv4 is UTF-8 capable, A-labels on the wire are just plain wrong in principle, IMHO.  FWIW, I don't care whether it's possible to get the current A-label approach blessed by the IETF's i18n gurus.  This turns up in 12.6 as "MAY be in the form of an A-label".  My preference is that A-labels on the wire be "MUST NOT" - if there's important "running code", I might settle for "SHOULD NOT" with an explanation of the "running code" that requires ignoring that "SHOULD NOT" in order to keep that "running code" happy.

Comments: 

For strings that SHOULD be UTF-8, but aren't, what's the protocol requirement?  I think the requirement is 8-bit clean (e.g., MUST NOT force the most significant octet to zero, unless the string MUST be ASCII).  That should be stated as part of the string classification.

The redefinition of "SHOULD" in 12.2.2 is an invitation to confusion.  I suggest:
	SHOULD -> USHOULD, VSHOULD -> UVSHOULD & VMUST -> UVMUST
plus use of capitalized SHOULD/MUST in defining these terms.

The first paragraph of 12.3 does not distinguish utf8_should strings from utf8val_should strings - the "SHOULD" requirement to return an error if the string is not UTF-8 conflicts with the statement that utf8_should strings are not checked for UTF-8 validity - I think that error return requirement applies only to utf8val_should strings.

12.4.2 suggests that NFSv4 supports hex-encoded text forms of IPv4 addresses.  Is that correct and/or needed?  The usual textual form of IPv4 addresses is decimal encoding.

12.7.1.2:

   However, in any of the following situations, file names have to be
   treated as strings of characters and servers MUST return
   NFS4ERR_INVAL when file names that are not in UTF-8 format:

Would "characters" -> "Unicode characters" be consistent with what was intended?  If so, that change would make the text clearer.  If not, I'm confused.

12.7.1.3 uses lower-case "must" and "should".  Is that deliberate vs. upper-case.  In general, double-check all uses of lower-case "must" and "should" to make sure that they are intended.

12.7.1.5.2 would be improved by examples of what clients should and/or should not do in order to improve interoperability with servers that do not handle normalization in the fashion that the client expects.

12.7.2 - If link text is utf8_should, servers aren't supposed to check for valid UTF8.  Based on 12.2.3, it looks like link text is utf8val_should, for which this check is appropriate.

Nits:
- Saw one instance of NFKC garbled to NKFC.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, September 09, 2010 6:36 PM
> To: [email-masked]
> Subject: [nfsv4] Going forward on I18N in RFC3530 bis
>

---

From: <[email-masked]>
Date: Wed, 22 Sep 2010 12:31:20 -0400

Thanks for your comments.  Looking over your suggestions, they all look
reasonable.  Some of them have already been done in my current XML based
on comments from other people.  The others, with the exception of the
A-label issue, will definitely be addressed in the draft preceding
Beijing.

As for the ongoing A-labels debate, you aren't disagreeing with me.  I
was just looking for something that would cause debate to stop for a
brief time and when I found it, I thanked everybody and wrote something
down.  If you want to begin this debate again, I salute your fortitude.
I think your position is right, BTW, but I think we can live with what
is in the draft. 

-----Original Message-----
From: Black, David 
Sent: Wednesday, September 22, 2010 11:49 AM
To: Noveck, David; [email-masked]
Subject: RE: Going forward on I18N in RFC3530 bis

Dave,

I reviewed the i18n material in -04 (Section 12).  it looks fairly good,
but the details are now beyond my level of i18n expertise.  I suggest
that we get a real i18n expert to review this section in the next
version of the draft - I have a couple of candidate reviewers in mind.
Many thanks for the extensive effort that has clearly gone into this.

My current view of A-labels vs. U-labels is that I'm going to (try to)
insist on no A-labels, *unless* there is important "running code" that
depends on A-labels on the wire and that needs to be grandfathered.
A-labels exist because the DNS infrastructure is fundamentally ASCII.
Since NFSv4 is UTF-8 capable, A-labels on the wire are just plain wrong
in principle, IMHO.  FWIW, I don't care whether it's possible to get the
current A-label approach blessed by the IETF's i18n gurus.  This turns
up in 12.6 as "MAY be in the form of an A-label".  My preference is that
A-labels on the wire be "MUST NOT" - if there's important "running
code", I might settle for "SHOULD NOT" with an explanation of the
"running code" that requires ignoring that "SHOULD NOT" in order to keep
that "running code" happy.

Comments: 

For strings that SHOULD be UTF-8, but aren't, what's the protocol
requirement?  I think the requirement is 8-bit clean (e.g., MUST NOT
force the most significant octet to zero, unless the string MUST be
ASCII).  That should be stated as part of the string classification.

The redefinition of "SHOULD" in 12.2.2 is an invitation to confusion.  I
suggest:
	SHOULD -> USHOULD, VSHOULD -> UVSHOULD & VMUST -> UVMUST
plus use of capitalized SHOULD/MUST in defining these terms.

The first paragraph of 12.3 does not distinguish utf8_should strings
from utf8val_should strings - the "SHOULD" requirement to return an
error if the string is not UTF-8 conflicts with the statement that
utf8_should strings are not checked for UTF-8 validity - I think that
error return requirement applies only to utf8val_should strings.

12.4.2 suggests that NFSv4 supports hex-encoded text forms of IPv4
addresses.  Is that correct and/or needed?  The usual textual form of
IPv4 addresses is decimal encoding.

12.7.1.2:

Would "characters" -> "Unicode characters" be consistent with what was
intended?  If so, that change would make the text clearer.  If not, I'm
confused.

12.7.1.3 uses lower-case "must" and "should".  Is that deliberate vs.
upper-case.  In general, double-check all uses of lower-case "must" and
"should" to make sure that they are intended.

12.7.1.5.2 would be improved by examples of what clients should and/or
should not do in order to improve interoperability with servers that do
not handle normalization in the fashion that the client expects.

12.7.2 - If link text is utf8_should, servers aren't supposed to check
for valid UTF8.  Based on 12.2.3, it looks like link text is
utf8val_should, for which this check is appropriate.

Nits:

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
> situation with regard to I18N in RFC3530 and the current plan about
what
> The big issue discussed was whether we should wait for precis to
finish
> proceeding very fast, we should go ahead based on the current draft
plus
> There were arguments about his use of the word "patch" and the
probable
> draft of rfc3530-bis, targeted at the Beijing deadline.  May be able
to

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 22 Sep 2010 14:06:01 -0400

On Wed, Sep 22, 2010 at 11:48:44AM -0400, [email-masked] wrote:
> Dave,
> 
> I reviewed the i18n material in -04 (Section 12).  it looks fairly
> good, but the details are now beyond my level of i18n expertise.  I
> suggest that we get a real i18n expert to review this section in the
> next version of the draft - I have a couple of candidate reviewers in
> mind.  Many thanks for the extensive effort that has clearly gone into
> this.
> 

Last time I checked, the linux referral code would only follow a
referral if it was an A-label:

	http://www.ietf.org/mail-archive/web/nfsv4/current/msg07863.html

That may have changed.  However, it wouldn't be surprising if it were
common behavior to pass the referral name directly to non-idn-aware dns
interfaces...

> Since NFSv4 is UTF-8 capable, A-labels on the wire are just plain
> wrong in principle, IMHO.  FWIW, I don't care whether it's possible to
> get the current A-label approach blessed by the IETF's i18n gurus.
> This turns up in 12.6 as "MAY be in the form of an A-label".  My
> preference is that A-labels on the wire be "MUST NOT"

... and therefore that a server conforming to such a "MUST NOT" would
likely fail to operate with client implementations.

I'll freely admit I haven't been following this discussion, so apologies
if I'm misunderstanding what you ask.

--b.

> - if there's
> important "running code", I might settle for "SHOULD NOT" with an
> explanation of the "running code" that requires ignoring that "SHOULD
> NOT" in order to keep that "running code" happy.

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 22 Sep 2010 14:39:24 -0400

> common behavior to pass the referral name directly to non-idn-aware dns

The advantage of scripting is that you can easily change things when
they don't work:

getent ahostsv4 bücher.com | awk '/STREAM/ { print $1; }'
82.98.86.165

Cheers
  Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 22 Sep 2010 14:42:34 -0400

> getent ahostsv4 bücher.com | awk '/STREAM/ { print $1; }'

OK, good.

What's the deal with Solaris?

--b.

---

From: <[email-masked]>
Date: Wed, 22 Sep 2010 14:45:37 -0400

> if I'm misunderstanding what you ask.

No apology needed - that's definitely an example of "running code" ...

Thanks,
--David

> From: J. Bruce Fields [mailto:[email-masked]]
> Sent: Wednesday, September 22, 2010 2:06 PM
> To: Black, David
> > For strings that SHOULD be UTF-8, but aren't, what's the protocol requirement?  I think the
> requirement is 8-bit clean (e.g., MUST NOT force the most significant octet to zero, unless the
> string MUST be ASCII).  That should be stated as part of the string classification.
> >
> > The first paragraph of 12.3 does not distinguish utf8_should strings from utf8val_should strings -
> the "SHOULD" requirement to return an error if the string is not UTF-8 conflicts with the statement
> that utf8_should strings are not checked for UTF-8 validity - I think that error return requirement
> applies only to utf8val_should strings.
> >
> > 12.4.2 suggests that NFSv4 supports hex-encoded text forms of IPv4 addresses.  Is that correct
> and/or needed?  The usual textual form of IPv4 addresses is decimal encoding.
> >
> > 12.7.1.2:
> >
> > Would "characters" -> "Unicode characters" be consistent with what was intended?  If so, that
> change would make the text clearer.  If not, I'm confused.
> >
> > 12.7.1.3 uses lower-case "must" and "should".  Is that deliberate vs. upper-case.  In general,
> double-check all uses of lower-case "must" and "should" to make sure that they are intended.
> >
> > 12.7.1.5.2 would be improved by examples of what clients should and/or should not do in order to
> improve interoperability with servers that do not handle normalization in the fashion that the
> client expects.
> >
> > 12.7.2 - If link text is utf8_should, servers aren't supposed to check for valid UTF8.  Based on
> 12.2.3, it looks like link text is utf8val_should, for which this check is appropriate.
> >
> > Nits:

---

From: <[email-masked]>
Date: Wed, 22 Sep 2010 18:06:14 -0400

Correction to one of my comments ...

> string MUST be ASCII).  That should be stated as part of the string classification.

That should be "MUST NOT force the most significant bit in each octet to zero, unless the string MUST be ASCII" - some goblin ate a few words ...

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> I reviewed the i18n material in -04 (Section 12).  it looks fairly good, but the details are now
> beyond my level of i18n expertise.  I suggest that we get a real i18n expert to review this section
> in the next version of the draft - I have a couple of candidate reviewers in mind.  Many thanks for
> the extensive effort that has clearly gone into this.
> 
> My current view of A-labels vs. U-labels is that I'm going to (try to) insist on no A-labels,
> *unless* there is important "running code" that depends on A-labels on the wire and that needs to be
> grandfathered.  A-labels exist because the DNS infrastructure is fundamentally ASCII.  Since NFSv4
> is UTF-8 capable, A-labels on the wire are just plain wrong in principle, IMHO.  FWIW, I don't care
> whether it's possible to get the current A-label approach blessed by the IETF's i18n gurus.  This
> turns up in 12.6 as "MAY be in the form of an A-label".  My preference is that A-labels on the wire
> be "MUST NOT" - if there's important "running code", I might settle for "SHOULD NOT" with an
> explanation of the "running code" that requires ignoring that "SHOULD NOT" in order to keep that
> "running code" happy.
> 
> Comments:
> 
> Would "characters" -> "Unicode characters" be consistent with what was intended?  If so, that change
> would make the text clearer.  If not, I'm confused.
> 
> 12.7.1.3 uses lower-case "must" and "should".  Is that deliberate vs. upper-case?  In general,

---

From: <[email-masked]>
Date: Wed, 29 Sep 2010 21:46:20 -0400

A goblin ate the words in *September"?  If this starts happening in
August, we should really start getting worried about RFC integrity :-) 

-----Original Message-----
From: Black, David 
Sent: Wednesday, September 22, 2010 6:06 PM
To: Noveck, David; [email-masked]
Subject: RE: Going forward on I18N in RFC3530 bis

> For strings that SHOULD be UTF-8, but aren't, what's the protocol
requirement?  I think the
> string MUST be ASCII).  That should be stated as part of the string
classification.

That should be "MUST NOT force the most significant bit in each octet to
zero, unless the string MUST be ASCII" - some goblin ate a few words ...

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
> I reviewed the i18n material in -04 (Section 12).  it looks fairly
good, but the details are now
> My current view of A-labels vs. U-labels is that I'm going to (try to)
insist on no A-labels,
> explanation of the "running code" that requires ignoring that "SHOULD
NOT" in order to keep that
> For strings that SHOULD be UTF-8, but aren't, what's the protocol
requirement?  I think the
> The first paragraph of 12.3 does not distinguish utf8_should strings
from utf8val_should strings -
> 12.4.2 suggests that NFSv4 supports hex-encoded text forms of IPv4
addresses.  Is that correct
> Would "characters" -> "Unicode characters" be consistent with what was
intended?  If so, that change
> 12.7.1.3 uses lower-case "must" and "should".  Is that deliberate vs.
upper-case?  In general,
> 12.7.1.5.2 would be improved by examples of what clients should and/or
should not do in order to
> 12.7.2 - If link text is utf8_should, servers aren't supposed to check
for valid UTF8.  Based on
what
finish
plus
probable
to