The 'news' and 'nntp' URI Schemes
draft-ellermann-news-nntp-uri-11

[Ballot discuss]
Section 1., paragraph 1:
> This memo extracts the 'news' and 'nntp' URI schemes from it to allow
> that material to remain on standards track if [RFC1738] is moved to
> "historic" status.

  Discuss-discuss. Obsolete != historic. The "Obsoletes: 1738 (if
  approved)" is clear, what remains unclear is whether this document
  also wants us to move 1738 to historic. (And if yes, we need a
  management item on that, and the sentence above needs to be
  rephrased.)

[Ballot comment]
Section 2.2:
>  in the style of the *NIX "find" command.

A proper reference to what you mean when you say "*NIX find" (e.g., IEEE Std 1003.1-2001) would improve the specification.

[Ballot discuss]
Section 2.3:
>  This memo doesn't specify a query part introduced by a question mark
>  "?" or a fragment introduced by a number sign "#" for the 'news' and
>  'nntp' URI schemes, but some implementations are known to use query
>  parts internally to address parts of a composite media type [RFC2046]
>  in Multipurpose Internet Mail Extensions (MIME).

This discussion of the fragment URI component is technically incorrect
or misleading.  RFC 3986 section 3.5 defines the fragment portion of a
URI as independent of the URI scheme and dependent on the media type of
the resource.  So, a URI scheme can not define a meaning for the
fragment component; all URI schemes may have a fragment component and
the meaning is defined by the media type of the resource.

The discussion of the query component is fine although advice to improve
interoperability would result in a better spec.

Section 8.2

I have not fully groked DDDS (RFC 3401-3405) and thus do not consider
myself a qualified expert to review DDDS registrations.  If Lisa
considers herself a qualified expert for such reviews I have no problem
advancing this specification.  Otherwise the IESG needs to identify and
designate an RFC 3405 expert reviewer to verify this section meets the
requirements in RFC 3405 / BCP 65 laid down by section 3.1.2.

[Ballot discuss]
Some of the comments in ABNF are potentially misleading. For example,

  mid-left        = 1*( mid-atext / "." ) /      ;
                    ( "%22" mid-quote "%22" )    ;

seems to suggest that the former alternative is equal to dot-atom-text
rule in RFC 2822, and the latter is equal to no-fold-quote rule in
userfor-12. The document actually does say that the Message-ID syntax
here is not identical to msg-id-core in usefor-12, but I'd suggest
adding a sentence or two more.

Similarly, the document should explain why the "group" ABNF rule is
not identical to the "newsgroup-name" rule in usefor-12 (probably a
good reason exists).

Most likely example.com/org/net domain names and RFC3330 documentation
IPv4 addresses should be used instead of real ones.

[Ballot discuss]
Some of the comments in ABNF are potentially misleading. For example,

  mid-left        = 1*( mid-atext / "." ) /      ;
                    ( "%22" mid-quote "%22" )    ;

seems to suggest that the former alternative is equal to dot-atom-text
rule in RFC 2822, and the latter is equal to no-fold-quote rule in
userfor-12. The document actually does say that the Message-ID syntax
here is not identical to msg-id-core in usefor-12, but I'd suggest
adding a sentence or two more.

Similarly, the document should explain why the "group" ABNF rule is not identical to the "newsgroup-name" rule in usefor-12 (probably a good reason exists).

Most likely example.com/org/net domain names and RFC3330 documentation
IPv4 addresses should be used instead of real ones.

[Ballot comment]
I think Section 8.2 would be significantly improved by a short
explanation on why this DNS record should be added, and how new
software might benefit from its existence (given that it doesn't exist
today, no client uses it, right?). The text should also explain why no
corresponding DNS record is added for "news" scheme, especially given
that the rest of the document seems to say that using "news" is
usually a better idea.

[Ballot discuss]
Some of the comments in ABNF are potentially misleading. For example,

  mid-left        = 1*( mid-atext / "." ) /      ;
                    ( "%22" mid-quote "%22" )    ;

seems to suggest that the former alternative is equal to dot-atom-text
rule in RFC 2822, and the latter is equal to no-fold-quote rule in
userfor-12. The document actually does say that the Message-ID syntax
here is not identical to msg-id-core in usefor-12, but I'd suggest
adding a sentence or two more.

Most likely example.com/org/net domain names and RFC3330 documentation
IPv4 addresses should be used instead of real ones.

[Ballot discuss]
There has not been a response to the Last Call comments from
  Charles Lindsey.  I sent a message on 21-Mar-2008 encouraging
  a response, but I still have not seen one.

  At least these two concerns deserve a response:

  1. The proposed syntax may be totally unnecessary when RFC2822-bis
  (draft-resnick-2822upd-06.txt) comes to pass, which is likely to be
  quite soon, and if the USEFOR-draft (draft-ietf-usefor-usefor-12.txt)
  is then updated to reflect it.  Charles has initiated a discussion on
  the USEFOR list to consider such an update.

  2. There is some disagreement about how to use "wildmats" as definined
  in  RFC3977.

IANA Last Call comments:

Action #1:
Upon approval of this document, the IANA will make the following
changes in "Uniform Resource Identifer (URI) Schemes per
[RFC4395]" located at
http://www.iana.org/assignments/uri-schemes.html
sub-registry "Permanent URI Schemes"

OLD:
URI Scheme Description Reference
news USENET news [RFC1738]
nntp USENET news using NNTP access [RFC1738]


NEW:
URI Scheme Description Reference
news USENET news [RFC-ellermann-news-nntp-uri-09.txt]
nntp USENET news using NNTP access [RFC-ellermann-news-nntp-uri-09.txt]


Action #2:
Upon approval of this document, the IANA will make the following
assignment in the "Uniform Resource Identifer (URI) Schemes per
[RFC4395]" registry located at
http://www.iana.org/assignments/uri-schemes.html
sub-registry "Historical URI Schemes"

URI Scheme Description Reference
snews NNTP over SSL/TLS [RFC-ellermann-news-nntp-uri-09.txt][RFC4642]


Action #3:

IANA will add the NAPTR record as described in section 8.2 to the
uri.arpa zone.


Action #4:

Upon approval of this document, the IANA will remove the following
assignment from "Application Media Types" at
http://www.iana.org/assignments/media-types/application/

news-message-id  [RFC1036][Spencer]

The following will be added to the "Access Types" registry located at
http://www.iana.org/assignments/access-types
Access Type Name Reference
---- ----------------------------------------------------- ---------
tbd news-message-ID [RFC1036][Spencer][RFC-ellermann-news-nntp-uri-09.txt]


We understand the above to be the only IANA Actions for this
document.