Re: [art] Comments on RFC 6068

[Peter Occil <[e-mail]>]

My previous two messages are withdrawn, except that the observations I made about header fields may be useful when work begins on a future update to RFC 6068 (which I don't imply will happen soon).  In that sense, those observations are currently "for your information".

--Peter

From: John C Klensin
Sent: Saturday, August 4, 2018 5:07 PM
To: Peter Occil; [e-mail]
Subject: RE: [art] Comments on RFC 6068

Peter,

Your clarification doesn't really change my answer.  Unless you
can convince people that the text that you believe requires
clarification are simple and obvious errors, responses from this
list are not going to do you a lot of good.  Let me take just
your first case/request as an example...

--On Saturday, August 4, 2018 15:39 -0400 Peter Occil
<[e-mail]> wrote:

> The two sections I made are, rather, largely requests for
> clarification.  I abridge my previous message to give just
> those requests:
> 
> I. Use of "quoted-string" in mailto URIs
> 
> Is "quoted-string" in mailto URIs (after percent decoding)
> intended to allow whitespace within the quotation marks or the
> obsolete syntax in the "obs-qp" production?

As far as addresses in that context are concerned, you may get
responses from the list as to whether including whitespace in
that way is sensible (I personally believe that whitespace has
caused enough problems in actual mailbox names (what RFC 5322
and 6068 call <addr-spec>) and  that, despite its having some
legitimate uses, we should have deprecated it long ago and it is
clear to me that Section 4.4 of RFC 5322 attempts to do that),
but I can just about guarantee that some people, possibly for
historical reasons, have chosen to allow it and that others,
perhaps by accident or by conformance to 822 or 2822, have
chosen not to.  

Here, despite the efforts of at least some IAB members to do
away with it (see draft-thomson-postel-was-wrong) is where the
robustness principle comes in.  If someone is responsible for
specifying mailbox names that might have to be encoded in a
MAILTO URI, allowing whitespace in the local-part is probably
just looking for trouble.  By contrast, if one is validating a
MAILTO URI or passing the information it contains into the mail
system, one needs to accept these thing because they are valid
(in the mail system) and not accepting them is a recipe for
angry calls and complaints from users.

Of course, if your question also applies to hfvalue elements,
the logical answer is rather more clear if looked at from the
standpoint of the relevant mail protocols, notably RFC 5322,
because forcing

 MAILTO:[e-mail]?Subject="RE:CommentsonRFC6068"

rather that allowing

 MAILTO:[e-mail]?Subject="RE:%20Comments%20on%20RFC%2060
68"

would probably not make anyone happy, but, as I read it, the
prose part of Section 2 of 6068 is rather clear about that.

It seems to me that, if any of the above really needs
clarification sufficient for you to point to the standards-track
RFCs and say, with great confidence "I am justified in doing (or
not doing) XYZ", then no amount of agreement on this or any
other IETF list is going to do you any good because we just
don't clarify, or formally interpret, standards track
specifications that way.  Instead, we issue new documents that
remove the perceived ambiguity.  And that takes my back to the
suggestion that you generate an Internet Draft in my earlier
note.

    best,
     john