We launched into a discussion of characters we'll allow in the namespace.
The proposed recommendation is to accept dot, underscore, and dash,
as well as alphanumerics. Since CalNet is accepting all those, we
pretty much have to as well, though there may be confusion if joe.blow
is different than joe_blow. (JC) This happens sometimes with other services,
and it always seems that someone comes to UAS asking if his account name
can be changed, rather than forcing the other person to change (some
exceptions for faculty).
The official maximum length for CalNet is something very large, like 255
characters, but they recommend 30 as a max, and 20 for people who will
deal with Active Directory (due to MS silliness). (JC) We don't need
to specify a number of characters--we can just recommend that the
service accept names as long as is feasible. There was general assent to
this.
(JC) What will the policy be on name changes? With uclink, you have to
request it from UAS, and it has to be changed to something name-based.
We might not want to make the same restriction. (Gordon) Why not just
let people change to whatever they want? (JC) Workload on UAS. (Gordon)
How about an automated system instead? (Tom) When uclink first started,
there was a "chlogin" command users could run; it was seriously bad
juju. There needs to be some hoops people have to jump through.
We began the discussion of relaying rules. The geekier among us gave
some background into the relaying problem, and current practice on
uclink and socrates. (Tom) We do not want to roll out a system with
permissive relaying. SMTP AUTH isn't universally available (from the
client perspective), but we might want to require it. (JC) We should
tell the implementors to take the relaying issue under advisement,
not provide a narrow recommendation. (Tom) We should definitely
recommend that the service not allow insecure relaying from the outset.
We don't have to specify SMTP AUTH. (General agreement)
We then moved on to virus scanning. (Gordon) We should use whatever
resources the central campus is providing for virus scanning. (Ilona)
We're not sure what the central campus is providing; SNS was originally
talking about a single central virus server, then backed away from that.
uclink is going with TrendMicro VirusWall, but it has some problems
compared with what socrates is currently doing. (JC) "central campus"
isn't a great term; if we mean IST, we should say IST. There was
general agreement to include a generic recommendation to look at virus
scanning, and leverage other IST resources.
We briefly touched on spam tagging; the sentiment was we don't want to
make a specific recommendation in this area. A generic "spam is bad,
mm'kay" will do.
That seemed like the last of the decisions we have to make. I will begin
writing things up, and we will meet in two weeks to review the draft.
I'll work on it online, so you'll be able to see it as it gets written.
Our target of the February 26th ITAC meeting seems feasible.
-- Tom Holub (tom_holub@LS.Berkeley.EDU, 510-642-9069) College of Letters & Science 249 Campbell Hall
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 16:52:32 PST