"Bryan J. Smith" <[EMAIL PROTECTED]> writes:
> On Tue, 2006-06-20 at 12:12 +1200, Jim Pye wrote:
> > Matthew et al.
> > One topic that seems to be missing from the future exams is email.
> 
> To me, it's more than just e-mail.  I put this under the domain (in my 8
> domain model of services**): 
>   "Collaboration and Mail Services"  
> 
> What an ISP uses for e-mail is not what an enterprise WAN would.  An
> enterprise is going to be interested in shared folders, scheduling and
> other server-side stores and resolution.

Totally agree.  And level 3 is intended to focus on the enterprise.  You
mentioned 'ISP' a couple of times.  Is there some belief (from before my
time?) that lpic-1/2 is ISP focuses or something?


> **NOTE:  That list is here:  
>   http://en.linux.wikia.com/wiki/ELResource#Domains  

Bookmarked.  Thanks.


> I will be filling in the subdomains by concept (technology) and practice
> (actual services).  Eventually I'll write some tasks (and hopefully
> enlist the help of others so we'll have a real resource, and not just
> another set of "standalone" HOWTOs that don't help much).

Sounds great to me.  I know that I'll be pinching from it.


> E.g., you can get into a whole can of worms with authentication and
> access control on IMAPS.  That's why we really need the "auth/dir/name"
> exam -- because we don't need to recover those concepts, only how a IMAP
> service might use them.  ;->

You forgot the <record condition="broken"> tags :)


> That's why I split these two domains:  
> - Collaboration and Mail Services (enterprise WAN/Intranet services)
> - Internet and Web Services (most others, like ISP/ASP-oriented)

How about we do this?  I'd like to put together a more comprehensive road map
for LPIC-3 over the summer and present it at the TAC (Technical Advisory
Council) at LinuxWorld in SanFran (Aug) and Cologne (Nov) for review.

If there's anyone interested in participating in the TAC (meets twice a year
or so at LinuxWorlds), let me know.

Of course, all of this will be up on the wiki, so comments can be made at any
time.


> > Email Clients
> > Reading the discussions on Samba and requiring client configuration
> > knowledge. This topic could also have the issue of including or not
> > including configuration of email "client" software.
> 
> Again, I'd argue a "Desktop" exam instead.  We can quickly get lost with
> all the choices.  Remember, open standards-based services.  From there,
> people can choose solutions -- especially since there are always dozens
> of clients for any 1 open standard service.

ergh.  I don't even want to think about a desktop exam.  That sounds like a
nice 2010+ project.  Matt Szulik may even agree that the desktop is ready by
then ;)


> > * These 2 because they are OSS. However the exam may not include
> > specific scanners but how the MTAs allow integration of these type of
> > scanners. 
> 
> The MTA is going to be a tough one.  If we choose Postfix and Sendmail,
> a lot of their configuration (even if Postfix legacy compatibility for
> Sendmail) do overlap.  But there are others like QMail (yes, I know, not
> likely) and Exim (now this is used more than people realize), etc...
> How far we do go on "inclusion"?

IMO, being the default debian MTA really helps Exim popularity.


> I don't know if that can be so addressed so easily.

It is possible that we could do one 'mail and collab' exam that is postfix
centric, one that is sendmail centric, ... (there's that 'cost' thing to
worry about, though).  I don't think that it's fair to expect someone to pass
a test where the questions could be on any of them.

We may just have to pick a first MTA, fill out the other exam areas and then
look at supporting other MTAs...nice problem to have.  Let's get these first
ones done first...


> If you haven't noticed, I'm trying to build a domain that gives
> enterprise administrators and architects an Exchange replacement.
> Remember, just like ADS, Exchange is just a set of services.  In fact,
> Exchange is a rather poor solution and incomplete (unlike ADS) when it
> comes to collaboration -- it relies on a _lot_ of _client_-side
> resolution with Outlook.
> 
> Exchange is _not_ a true scheduling/collaboration back-end, just a store
> with intelligent client in Outlook.

I have a client that calls it lookOut.  enuf said.

Regards,
-- 
g. matthew rice <[EMAIL PROTECTED]>           starnix, toronto, ontario, ca
phone: 647.722.5301 x242                                  gpg id: EF9AAD20
http://www.starnix.com              professional linux services & products
_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/mailman/listinfo/lpi-examdev

Reply via email to