headers
Charles Lindsey | 6 Nov 2003 19:04
Picon
Picon

ietf-nntp Niggles

I have just completed a read-through of the latest draft (well, the
pre-1.txt actually, but I have checked 20.txt where necessary). I have
unearthed various niggles which could usefully be fixed (but only a couple
that could be considered serious).

P1.
   UNIX is a registered trademark of the X/Open Company Ltd.

Is that still correct this week? And if it is, is it "Ltd" or "Inc".

P17.

   o  A message-id MUST NOT contain octets other than printable US-ASCII
      characters.

Is is sufficiently clear that SP is "non-printable"? Some would argue that is
it printed, but it just so happens that the amount of ink deposited is zero.
Would do no harm to clarify.

   This specification does not describe how the message-id of an article
   is determined. If the server does not have any way to determine a
   message-id from the article itself, it MUST synthesise one (this
   specification does not require the article to be changed as a
   result).

This not immediately clear to those who have not followed our discussions.
Some reference to Appendix B2 would be helpful here.

P25.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Russ Allbery | 7 Nov 2003 05:38
Picon
Favicon
Gravatar

Re: ietf-nntp Niggles

Charles Lindsey <chl <at> clerew.man.ac.uk> writes:

> P17.

>    o  A message-id MUST NOT contain octets other than printable US-ASCII
>       characters.

> Is is sufficiently clear that SP is "non-printable"? Some would argue
> that is it printed, but it just so happens that the amount of ink
> deposited is zero.  Would do no harm to clarify.

Printable characters are defined elsewhere in the draft, I believe.  We've
discussed this point before.

>    If the requested header is not present in the article or if it is
>    present but empty, a line for that article is included in the output

> That is not my understanding of the case when the requested header is
> absent from the article, and it is not consistent with what is said on
> the previous page:

We had a long conversation about this and I believe the above is correct.

>    If the information is available, it is returned as a multi-line
>    response following the 225 response code and contains one line for
>    each article where the relevant header line or metadata item exists
>    (note that unless the argument is a range including a dash, there
>    will be at most one line but it will still be in multi-line format).

I think this is the one that's incorrect; the output should contain one
(Continue reading)

Permalink | Reply | 3 comments |
headers
ned+ietf-nntp | 7 Nov 2003 10:01

Re: ietf-nntp Niggles

> P62.

>    An extension is either a private extension or else it is included in
>    the IANA registry and is defined in an RFC. Such RFCs either must be
>    on the standards track or must define an IESG-approved experimental
>    protocol.

> My reading of RFC 2026 is that the IESG does not approve experimental
> protocols. There is provision for the IESG to "review" them if the RFC Editor
> considers them to be a bit "iffy" and to insert a "disclaimer" or take other
> action, but failure to do that does not actually imply "approval".

Well, yes and no. What happens in practice is that the RFC Editor runs all
experimental protocol submissions it receives by the IESG. The IESG then
makes a recommendation as to whether or not the document should be
published as an RFC. The RFC Editor can override the IESG if it wants
to, but when this happens the IESG can (and almost always does) attach
a note to the document explaining why the IESG thinks it is a bad idea.

Actual cases where the RFC Editor and the IESG disagree are rare, and I believe
they have become rarer over time.

However, all this is totally irrelevant to the matter at hand. Why? Because the
whole point of including the phrase "IESG-approved" is to make IESG approval an
*additional* requirement for publication of an NNTP extension specification.
Just because this requirement does not normally exist for publication of an
experimental extensions doesn't mean a specification can't add it.

SMTP extensions are similarly constrained (I suspect this is where the idea
came from) and this set of constraints has worked very well in practice.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Forrest J. Cavalier III | 7 Nov 2003 18:33

ietf-nntp Interesting article in the wild.

I saw an interesting article in the wild.  I noticed it because of an
XOVER which was longer than 2048 characters.  Headers below.

I don't know chinese, so I do not know if this is legitimate.  Maybe
I should forward to the NNTP list?

Comments?

From: =?GB2312?B?TWlja3kgV29uZyCjqLqjyfrSu9Cmo6k=?= <mickywon <at> mac.com>
Organization: =?GB2312?B?zcDB+tautrwub24uY2E=?=
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20030925
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: talk.politics.china,alt.chinese.text
Subject: =?GB2312?B?ob7MqLbA09DA7aG/zKi2wNPrw/HX5dfUvvbIqA0KCQ0KCcyotsDT6w==?=
 =?GB2312?B?w/HX5dfUvvbIqA0KCQ0KCaHyIL3wINbTDQoJDQoJofEg1tC5stPrw6vA+sq3yc8=?=
 =?GB2312?B?1Pi24LTOse3Kvtans9bMqM3ltsDBoqOsusHO3s2z0rvWrtLio6zG5NS0s/bstg==?=
 =?GB2312?B?wdDE/rXEw/HX5dfUvvbA7cLbo6y1q9bQubK9qLn64eGx483qyKu37tDQtPPSuw==?=
 =?GB2312?B?zbPV/rLfIC4uLi4uLg0KCQ0KCaGhoaG+xdTCyq6wy8jVo6zP47jbw/exqLeise0=?=
 =?GB2312?B?ztLS8sH1u9vH5MrCvP7T0LjQtvi3orXE0rvGqrbMxsChttHUwtvX1NPJzt69+w==?=
 =?GB2312?B?x/iht6Osw/exqLHgvK3Tw7XEserM4srHobbB9bvbx+TKwrz+o6y2/squyP3M9Q==?=
 =?GB2312?B?0KfTptSk0d2ht6Gj1K3OxNLRv6/stsnPxtqxvr+vobi428jLuNvH6aG5wLihow==?=
 =?GB2312?B?DQoJDQoJoaGhocP3sajXvs7Et6Kx7eHho6y12sj9zOzD97GowtvMs7Dmt6Kx7Q==?=
 =?GB2312?B?s8K2rM7E1cKjrLXazuXM7NbQubLOxLvjsai3orHtobi98NbTz8jJ+s7wzvO1vA==?=
 =?GB2312?B?tsHV36G5zsTVwqOstrzV67bUztLS/dPDw6vU87ar0ru+xcj9wfnE6tTa0dOwsg==?=
 =?GB2312?B?vPvDwLn6vMfV38u5xbW1xMy4u7ChuNans9bMqM3lyMvD8dX5yKG2wMGitcTVvQ==?=
 =?GB2312?B?trehuaOsy7XO0qG4yLG3psD6yrezo8q2obmjrKG4t8fA7dDU0uLG+Nau1fmhuQ==?=
 =?GB2312?B?IC4uLi4uLiCzxsOrtbHKsbXE0dTC29a7ysfWp7PWzKjN5cjLw/GhuMbwwLTU7A==?=
 =?GB2312?B?t7SjrLbAwaLsttazw/HV39auzeKjrKG4vviyu8rH1qez1rXEzKi2wKG5oaMNCg==?=
 =?GB2312?B?CQ0KCaGhoaHDq8rHt/HU+Nb31cXMqLbAo7+yu732yea8sMD6yrfKwsq1tcSzzg==?=
(Continue reading)

Permalink | Reply | 0 comments |
headers
Clive D.W. Feather | 11 Nov 2003 12:16

Re: ietf-nntp Niggles

Charles Lindsey said:
> P1.

In future, please use section numbers rather than page numbers, or use
both. It makes it easier to find in the source. Thanks.

>    UNIX is a registered trademark of the X/Open Company Ltd.
> 
> Is that still correct this week? And if it is, is it "Ltd" or "Inc".

It's "The Open Group" (who were X/Open). See <http://lwn.net/Articles/33409/>.

> P17.
>    o  A message-id MUST NOT contain octets other than printable US-ASCII
>       characters.
> 
> Is is sufficiently clear that SP is "non-printable"?

Yes. The term is adequately defined in both sections 2 and 9.

>    This specification does not describe how the message-id of an article
>    is determined. If the server does not have any way to determine a
>    message-id from the article itself, it MUST synthesise one (this
>    specification does not require the article to be changed as a
>    result).
> 
> This not immediately clear to those who have not followed our discussions.
> Some reference to Appendix B2 would be helpful here.

Added.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Charles Lindsey | 10 Nov 2003 12:25
Picon
Picon

Re: ietf-nntp Niggles

In <87sml0ssh4.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>Charles Lindsey <chl <at> clerew.man.ac.uk> writes:

>>    o  A message-id MUST NOT contain octets other than printable US-ASCII
>>       characters.

>Printable characters are defined elsewhere in the draft, I believe.  We've
>discussed this point before.

OK, I found the definition.

>>    If the requested header is not present in the article or if it is
>>    present but empty, a line for that article is included in the output

>> That is not my understanding of the case when the requested header is
>> absent from the article, and it is not consistent with what is said on
>> the previous page:

>We had a long conversation about this and I believe the above is correct.

Hmmm! WHat does XHDR do? In RFC 2980 I find:

   Some implementations will return "(none)" followed by a period on a
   line by itself if no headers match in any of the articles searched.
   Others return the 221 response code followed by a period on a line by
   itself.

And what Stan Barber's reference implementation does is
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jeffrey M. Vinocur | 22 Nov 2003 06:57

draft-ietf-nntpext-tls-nntp-01.txt

I don't know why we didn't get a publication announcement, but I've 
released a new version of the TLS draft; comments please.

http://www.ietf.org/internet-drafts/draft-ietf-nntpext-tls-nntp-01.txt

For reference, changes since draft-ietf-nntpext-tls-nntp-00.txt are --

     New:
     o  Text needed to comply with extensions framework guidelines:
        -  Allows 483 to be returned for most commands
        -  No pipelining
        -  Not impacted by MODE READER
     o  Examples section

     Changed:
     o  Welcome banner is *not* reissued after STARTTLS
     o  STARTTLS on an already-secure link gives 502 (not 580)
     o  Failed negotiation gives 580 on the reestablished insecure link
     o  Removed MULTIDOMAIN, need is resolved by RFC 3546 (a SHOULD)
     o  Removed definition of 483, which is now included in base spec
     o  Use HDR instead of PAT in the LIST EXTENSIONS example

     Clarified:
     o  When the capability can be advertised
     o  The specifc octet where encrypted session begins

     Other:
     o  Reformatting to match base spec style
     o  Assorted updates of phrasing and typographical varieties
     o  Updated several references per new versions of documents
(Continue reading)

Permalink | Reply | 33 comments |
headers
Charles Lindsey | 10 Nov 2003 13:34
Picon
Picon

Re: ietf-nntp Niggles

In <01L2QD830SII00HOW2 <at> mauve.mrochek.com> ned+ietf-nntp <at> innosoft.com writes:

>However, all this is totally irrelevant to the matter at hand. Why? Because the
>whole point of including the phrase "IESG-approved" is to make IESG approval an
>*additional* requirement for publication of an NNTP extension specification.
>Just because this requirement does not normally exist for publication of an
>experimental extensions doesn't mean a specification can't add it.

>SMTP extensions are similarly constrained (I suspect this is where the idea
>came from) and this set of constraints has worked very well in practice.

OK, I see similar wording in RFC 2821. But I would still have thought that
"IESG-accepted" conveyed better what actually happens.

Does the IESG ever add "The IESG approves of this" to an Experimental RFC?
Surely what the IESG does in actual practice is to "accept" the RFC (by
letting the RFD Editor publish it). That seems to mean "this is not (yet)
a proposed standard, but the IESG is happy for this experiment to go
ahead".

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
(Continue reading)

Permalink | Reply | 1 comment |
headers
Internet-Drafts | 18 Nov 2003 21:09
Picon
Favicon

I-D ACTION:draft-ietf-nntpext-tls-nntp-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NNTP Extensions Working Group of the IETF.

	Title		: Using TLS with NNTP
	Author(s)	: J. Vinocur, C. Newman
	Filename	: draft-ietf-nntpext-tls-nntp-01.txt
	Pages		: 11
	Date		: 2003-11-18
	
This memo defines an extension to the Network News Transport
Protocol [NNTP] to provide connection-based encryption (via
Transport Layer Security [TLS]).  The primary goal is to provide
encryption for single-link confidentiality purposes, but data
integrity and (optional) certificate-based peer entity
authentication are also possible.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nntpext-tls-nntp-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-nntpext-tls-nntp-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |

Gmane