ietf-nntp Re: nntp-extensions draft-ballou-nntpsrch-00.txt

[Chris Lewis]

In message "Re: ietf-nntp Re: nntp-extensions draft-ballou-nntpsrch-00.txt", 
'bhern at netscape.com' writes:

>> A more complex solution, having nnrpd place the profile in a file for
>> later retrieval causes storage management issues not seen before.

>This is what I imagined implementations would do. It's not really that
>hard.

>> I tend to not like the idea of the server having to retain any more
>> client-specific state than "current group" and "current article number".

>Personally, I like the idea of pushing more onto the server and making
>the clients more lightweight. 

I'm not suggesting it's particularly hard to implement.  However, you may
want to consider:

	1) people adjusting headers etc - how do you identify which profile
	   belongs to whom?  (short of full authentication)
	2) ensuring that person A's profile isn't exposed to person
	   B - confidentiality concerns.  (short of full authentication)
	3) storage management - lifetime expectancies?  Cleanup?  Size?
	   Formats?  Another expire program?
	4) Why is this different than the newsgroup listing in the client-side
	   .newsrc equivalent?  If we were to do this, shouldn't we push
	   the .newsrc at the server too?  The .newsrc could be 10s of
	   kilobytes.  That's a significant amount of storage on a large
	   server (ie: around 50Mb on one of our servers).

This introduces a whole new ballgame of per-user storage and a new
security dimension to the server.

I think it would be better to push storage of profiles onto the client - it's
no big deal to implement it on a client as an adjunct to the already-necessary
per-user .newsrc equivalent.  Even if you contemplated having the server
proactively kick a client with a search match, there's no point in trying
that unless the client already has an established connection, and has already
downloaded its search profile to the server.

I think the only advantage of having persistance on the server is so that
the server could scan inbound articles as they arrive and produce listings
of articles to present to the user when they next log in.  Do we need this?
Does doing it this way end up cheaper than doing it when the client asks
for it?
--
Chris Lewis, Senior Network Security Analyst, Nortel.
clewis at nortel.ca; Dept 4C16, Ottawa, Canada.  (613) 763-2935.