Re. [Oberon] helpful additions to Oberon.Text

[eas-lab at absamail.co.za]

> Here are a few additions to InitCommands 
> in Oberon.Text which I would find helpful.  
> I expect these additions would save a 
> novice some time as well as grief.
> 
> 		{ !FileSystem.Mount  USR   AosFS IDEm#0n ~ }
> 		{ !FileSystem.SetDefault USR }
> 		{ FileSystem.Watch }
>     	{ Diskettes.Install }  {* Most PCs have a floppy drive. *}
>     	...
> 		{ NetSystem.SetUser
>                dialup:<Userid>:<Password>@<ServiceName> ~ } 
> 			   {* Most users prefer to not type passwords. *}

Did you miss my discussion about not using "@" as a parsing token
by assuming that it won't be included in the <Password>
or <ServiceName> strings.    The <Password> could be allocated
(perhaps even computer generated), by 'outsiders' - eg. the ISP.
Ie. not your choice.

Here's a dialogue with the man who wrote the ppp book:-

 Chris Glur -----------------------------------------------------

From: James Carlson <james.d.carlson at sun.com>
Subject: Re: password, special chars to be quoted ?

eas-lab at absamail.co.za writes:
> Does this: 'quotes around special chars' apply to software that reads
> the user-name/password before ppp mode,  ie. has nothing to do
> with what is sent to ppp ?

I don't use any such software.  If there is such software, you'll have
to consult its documentation.

> Previously login user-name/password usually had no special characters.
> Then my latest ISP allocated me (perhaps computer generated) a 
> user-name including a "@".    This messed up my software (Oberon S3), 
> which 'used' the following:
> 		NetSystem.SetUser pap:<user>[:<password>]@<provider> ~
> 
> Ie. (in this context) it used "@" as a token separator.

Yeah, that looks like a bummer.  Specifying "\@" may work.

> Some other Oberon S3 users say that my ISP is 'bad'.

Bah!  There are no restrictions on a user name string.  This software
is wrong.

More that that, such an interpretation is strictly incompatible with
NAIs (Proposed Standard RFC 2486), which are often used as "user
names" in this context.  What could they be thinking?

> I believe that no RFC excludes any special characters in the 
> login user-name/password nor pap user-name/password.
> 
> Is this right ?

You're right.  In fact, RFCs 1334 (for PAP) and 1994 (for CHAP)
describe the peer name field as just a sequence of octets -- you can
put *any* sequence of octets in there, including control characters
and even NUL.  Most implementations will fail miserably when faced
with what the RFC demands, so don't try that at home, kids.  ;-}

This is why interface specifications for software are really
important.  Without them, people will just randomly yank characters
(such as '@') out of the syntax and assign them new meanings.

-- 
James Carlson, Solaris Networking         <james.d.carlson at east.sun.com>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677



 Chris Glur.