headers
Russ Allbery | 8 Sep 2003 03:23
Picon
Favicon
Gravatar

Re: ietf-nntp draft-ietf-nntpext-base-19

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

> There exists the possibility (shudder) that other variants of the MODE
> command might exist in the future, in which case the principles you set
> out below would apply pretty much as you have written them. Should it
> all be written in a more general form to cover that possibility?

Given that the MODE command is in essence a primitive extension mechanism
which is probably superseded by LIST EXTENSIONS, I hope that we'll be able
to get away without using it any more.  So I wouldn't bother making the
text general unless the issue actually arises, since hopefully it won't.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
Permalink | Reply | 2 comments |
headers
Russ Allbery | 8 Sep 2003 03:26
Picon
Favicon
Gravatar

Re: ietf-nntp draft-ietf-nntpext-base-19

Clive D W Feather <clive <at> demon.net> writes:

> New wording for 5.2.2:

[...]

>     At all points in the session those commands currently listed by LIST
>     EXTENSIONS must be available.  Therefore, if a command defined by an
>     extension (including those in section 8) is only available before or
>     after a MODE READER command, or if the effects of the extension will
>     be changed by the command, the LIST EXTENSIONS command MUST produce
>     different results that indicate the differences.

I think instead of "the effects of the extension" you want to say "the
parameters of the extension" or whatever term we used for the additional
arguments after the first word of the line in LIST EXTENSIONS.  Effects
seems to imply that if the command does something different before MODE
READER than after MODE READER, LIST EXTENSIONS must change (even if the
extension is advertised the same way at both points).  This, of course,
would be a horrible way to design a command, but I also don't think it's
what we want to say.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
(Continue reading)

Permalink | Reply | 4 comments |
headers
Russ Allbery | 8 Sep 2003 03:36
Picon
Favicon
Gravatar

ietf-nntp Last major open issue (48x return codes)

Apart from the UTF-8 issues (which I think should now be cleared up
because the new UTF-8 RFC was approved), this is the last open issue in
draft-19:

   If the client is not authorized to use the specified facility when
   the server is in its current state, then either the response code 480
   or the response code 502 MUST be returned. The response code 480
   SHOULD be used if a different command (for example, an extension used
   to present credentials) might change the server state so that the
   command is permitted. The response code 502 SHOULD be used if the
   server wishes to indicate that it is necessary to terminate the
   connection and start a new one with the appropriate authority before
   the command can be used. Since it is not always possible to clearly
   distinguish these two cases, a server MAY issue either of these
   response codes for either case. (Note that the server MUST NOT close
   the TCP connection immediately after a 502 response except at the
   initial connection (Section 5.1) and with the MODE READER (Section
   5.2) command.)

   OUTSTANDING ISSUE

      This isn't a complete solution to the 480 issue; what about the
      TLS extension, which uses 483 to mean "you need encryption".
      Should 480 be used for other than "you need authentication"? What
      code should be used to mean "can't do AUTH until after MODE
      READER"?

      Do we need a more generic mechanism for "you must invoke extension
      X to do Y"?
(Continue reading)

Permalink | Reply | 6 comments |
headers
Charles Lindsey | 8 Sep 2003 12:22
Picon
Picon

Re: ietf-nntp Last major open issue (48x return codes)

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

>For the latter question, I think reserving 48x codes to mean that a
>command is unavailable unless some authentication or privacy extension is
>invoked is the best approach.

Something like that, but are there other circumstances? Essentially it is
saying "I can't let you do that unless you jump through some hoops first"
(hopefully the accompanying text and/or the value of 'x' will tell you
which hoop).

Clearly, the obvious hoops are authentication and privacy, but could there
be others we have not thought of yet, and should the wording be broad
enought to cover them in the future?

--

-- 
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
Permalink | Reply | 5 comments |
headers
Russ Allbery | 8 Sep 2003 17:41
Picon
Favicon
Gravatar

Re: ietf-nntp Last major open issue (48x return codes)

Charles Lindsey <chl <at> clerew.man.ac.uk> writes:
> Russ Allbery <rra <at> stanford.edu> writes:

>> For the latter question, I think reserving 48x codes to mean that a
>> command is unavailable unless some authentication or privacy extension
>> is invoked is the best approach.

> Something like that, but are there other circumstances?

Not that I can think of; do you have anything in mind?

> Clearly, the obvious hoops are authentication and privacy, but could
> there be others we have not thought of yet, and should the wording be
> broad enought to cover them in the future?

Authentication and privacy are pretty huge buckets that should encapsulate
a world of extensions.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
Permalink | Reply | 4 comments |
headers
Ken Murchison | 8 Sep 2003 18:10

Re: ietf-nntp Last major open issue (48x return codes)


Russ Allbery wrote:
> Charles Lindsey <chl <at> clerew.man.ac.uk> writes:
 >
>>Clearly, the obvious hoops are authentication and privacy, but could
>>there be others we have not thought of yet, and should the wording be
>>broad enought to cover them in the future?
> 
> 
> Authentication and privacy are pretty huge buckets that should encapsulate
> a world of extensions.

We could even generalize these as "security" which is probably a bigger 
bucket.

--

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
Permalink | Reply | 3 comments |
headers
Russ Allbery | 8 Sep 2003 18:17
Picon
Favicon
Gravatar

Re: ietf-nntp Last major open issue (48x return codes)

Ken Murchison <ken <at> oceana.com> writes:
> Russ Allbery wrote:

>> Authentication and privacy are pretty huge buckets that should
>> encapsulate a world of extensions.

> We could even generalize these as "security" which is probably a bigger
> bucket.

That sounds fine to me; I certainly have no objections.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
Permalink | Reply | 2 comments |
headers
Jeffrey M. Vinocur | 9 Sep 2003 01:11

Re: ietf-nntp Last major open issue (48x return codes)

On Mon, 8 Sep 2003, Russ Allbery wrote:

> Ken Murchison <ken <at> oceana.com> writes:
> > Russ Allbery wrote:
> 
> >> Authentication and privacy are pretty huge buckets that should
> >> encapsulate a world of extensions.
> >
> > We could even generalize these as "security" which is probably a bigger
> > bucket.
> 
> That sounds fine to me; I certainly have no objections.

Especially once (some day) it's all SASL-based, and thus the distinction
isn't even relevant to the NNTP negotiation.  (That is, if the server
admin is looking to have authentication required, encryption optional,
then the server will advertise only the relevant mechanisms.)  I can't see 
any reason to have them distinguished in that case.

--

-- 
Jeffrey M. Vinocur
jeff <at> litech.org

_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
Permalink | Reply | 1 comment |
headers
Ken Murchison | 9 Sep 2003 01:17

Re: ietf-nntp Last major open issue (48x return codes)


Jeffrey M. Vinocur wrote:
> On Mon, 8 Sep 2003, Russ Allbery wrote:
> 
> 
>>Ken Murchison <ken <at> oceana.com> writes:
>>
>>>Russ Allbery wrote:
>>
>>>>Authentication and privacy are pretty huge buckets that should
>>>>encapsulate a world of extensions.
>>>
>>>We could even generalize these as "security" which is probably a bigger
>>>bucket.
>>
>>That sounds fine to me; I certainly have no objections.
> 
> 
> Especially once (some day) it's all SASL-based, and thus the distinction
> isn't even relevant to the NNTP negotiation.  (That is, if the server
> admin is looking to have authentication required, encryption optional,
> then the server will advertise only the relevant mechanisms.)  I can't see 
> any reason to have them distinguished in that case.

Good point, but I don't think that PLAIN+TLS will go away any time soon, 
so the authentication (AUTHINFO SASL) and privacy (STARTTLS) distinction 
will still need to be made.

--

-- 
Kenneth Murchison     Oceana Matrix Ltd.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Clive D.W. Feather | 9 Sep 2003 14:21

Re: ietf-nntp draft-ietf-nntpext-base-19

Russ Allbery said:
>> There exists the possibility (shudder) that other variants of the MODE
>> command might exist in the future, in which case the principles you set
>> out below would apply pretty much as you have written them. Should it
>> all be written in a more general form to cover that possibility?
> Given that the MODE command is in essence a primitive extension mechanism
> which is probably superseded by LIST EXTENSIONS, I hope that we'll be able
> to get away without using it any more.  So I wouldn't bother making the
> text general unless the issue actually arises, since hopefully it won't.

While I agree with that, the text in the paragraph beginning "At all
points" is actually generic to any command that changes what's available.
As such, it perhaps belongs with LIST EXTENSIONS rather than MODE READER.
That is, I would delete it and give LIST EXTENSIONS wording the text:

    At all points in the session those commands currently listed by
    LIST EXTENSIONS must be available. Therefore, if a command defined
    by an extension (including those in Section 8) is only available
    before or after a particular command (such as MODE READER), or if
    the effects of the extension will be changed by the command, the
    LIST EXTENSIONS command MUST produce different results that indicate
    the differences.

Any objections?

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive <at> davros.org>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646
(Continue reading)

Permalink | Reply | 1 comment |

Gmane