Re: [EAI] Shepherd report review of mailinglist-02

["Martin J. Dürst" <[e-mail]>]

Hello Joseph, John, John, and others,


On 2012/07/11 1:13, Joseph Yee wrote:

> (11) Section 3.1

> In paragraph 3:
>     The most commonly-used URI schemes in List-* headers tend to
> be HTTP
>     and mailto, although they sometimes include HTTPS and FTP,
> and in
>     principle can contain any valid URI.
>
> Use "MAILTO", not "mailto" unless you want you waste your time
> and ours in a silly argument.

Scheme names are usually written lower-case, so I suggest to streamline 
this as:

The most commonly-used URI schemes in List-* headers tend to be http
and mailto, although they sometimes include https and ftp, and in
principle can contain any valid URI.


> Paragraph 4 is problematic because the whole state of IRIs is
> up in the air right now.  It might be better to say something
> like:
>
>     Even if a scheme permits an internationalized form, it
>     should use a pure ASCII form of the URI described in
>     [RFC3986].  Future work may extend
>     these header fields or define replacements to directly
>     support non-encoded UTF-8 outside the ASCII repertoire in these
>     and other header fields, but in the absence of such extension
>     or replacement, non-ASCII characters can only be included by
>     encoding them as ASCII.

This text would work for me.

> That avoids references to anything but 3986, which is very
> stable.  Even though this is an Informational document, the
> statement as originally written creates normative references
> to 3867  and should create one to [I-D.duerst-iri-bis].  We
> really don't want to go there if it can be avoided.

That's fine with me, but I don't really see any problem with referencing 
RFC 3987.

> (12) While there have been periodic discussions in the
> community about whether the "Normative/ Informative" split
> really makes sense for Informational documents, the current
> rule is that it is required for the IETF Stream.  While we
> could, in principle, make an issue of it, it hardly seems worth
> it.  So please split the list up.   Note also that
> [I-D.duerst-iri-bis] does not appear to be  not cited in the
> current draft and the reference is outdated.  Please get rid of
> it unless you have reason to retain it _and_ are absolutely
> certain that reason doesn't involve a normative reference.

Yes, please. I think this is just a leftover from a previous version of 
the draft.


> I think that ends up with the following
>
> Normative:  RFC 3986; RFC6409 (marginal, but a full standard
> and hence harmless)
>
> Informative: RFC 2369, RFC 2919 (both mentioned only as
> examples)
>
> Questionable: RFC 3987 and RFC 6068  (used only as part of
> the specification of "the URI-encoded form" in Section 3.1).  I
> urge getting rid of them entirely since it is easy to have the
> discussion that is relevant to this document without them and
> they (especially 3987, which draft-ietf-iri-3987bis (the real
> [I-D.duerst-iri-bis] proposes to obsolete incompatibly.

As draft-ietf-iri-3987bis isn't yet done, its difficult to say exactly, 
but while there are many changes and tweaks in the details, the basic 
principles are exactly the same. Saying that you can't cite RFC 3987 
because there's a WG that is working on updating it would be about the 
same as saying you can't cite RFC 2616 (HTTP) because there's a WG 
working on updating it.

Regards,    Martin.