[Oberon] %XX/W3C-encoding not applicable to ISP login

[easlab at absamail.co.za]

I hope this finally puts this argument to rest.
You can read the full thread on :
Newsgroups: comp.protocols.ppp,comp.os.linux.networking
Subject: Re: dail-up ISP login can't do W3C encoding.

I've included here, what I consider as the essentail comments of THE MAN
who wrote the 'ppp-book' : --
James Carlson, IP Systems Group                <james.d.carlson at 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
---------

James Carlson wrote:
> > >   - The existence of any particular encoding ability is merely a
> > >     feature of the software implementation.  I can't say I've *ever*
> > >     heard of %XX encoding being used here (or &foo; for that matter),
> > >     but it's certainly not impossible.
> > 
Chris Glur wrote:
> > BTW where in the 'chain' is %XX encoding implemented ? TCP ?
> 
> It's an application convention.  It's not related to TCP or PPP.

OK that clears up a BIG misconception of mine, you say:
  all the way through the internet the "%40" passes as these '3 chars',
  and the application can [or not] translate it to "@".

  Relating this to my specific problem, I don't see any reason why
  the ISP login process should translate "%40" to "@".
  Do you ?  

> > >   - Availability or non-availability of the encoding mechanism is a
> > >     non-issue.  If the ISP requires it for some reason, and the PPP
> > >     implementation you're using cannot do it automatically, then
> > >     you'll need to type "user%40realm.net" into that box or
> > >     configuration file instead of "user at realm.net".  Otherwise, you'll
> > >     just need to find a new ISP.
> > 
> > Then I'm mistaken: my whole argument has been that the ISP won't
> > translate '%40' to '@' before login/password.  I've hacked the 'dialler'
> > script to see "user$realm.net" and send "user%40realm.net" to the ISP.
> > My notebook has [to] have a different version of the software and I 
> > don't want to have to analyse and patch that too. 
> > If translate "%40" -> "@" worked that would be a quick solution;
> > but on the dialer which was hacked to work, testing by using "%61"
> > in place of "a" fails to login.  I'm really confused !
> 
> I still don't understand why you'd want to do any of that.  Did the
> ISP insist that this is how they want to see user names?  Or are you
> trying to work around some local bug that prevents the use of the
> ISP-required "@" sign?

1. The ISP allocated me the userID with an embedded "@" char.
2. The dialer assumes no userID will contain a "@" char. and uses
    "@" as the deliniter of the userID.
3.  The OS-users tell me that decoding to "%40" will solve my
    problem.
4. It doesn't solve the problem, apparently because the ISP login
    process has no reason to implement %xx decoding. 

--snip --

> > The only way I could still agree with your argument [and the oberon
> > users'] is if the ISP operates in 'dual mode':
> > 
> > IF the client 'starts talking ppp' 
> >      THEN the ISP replies with ppp;
> > ELSEIF the client 'starts talking <CR> '
> >     THEN the ISP replies with 'text-mode' until UserName & Password =OK;
> >           afterwhich:switch to ppp & Tx "Entering PPP mode".
> 
> That's precisely what a fair number of commercial dial-up servers did
> in the early 90s.  The "ELSEIF" part was commonly dropped later to
> save on service calls.  The expensive part of running any sort of
> public-facing business (like an ISP) is dealing with calls from
> confused users.  Eliminating text-mode dial-up helps eliminate those
> calls, as Windows supports plain old PPP right out of the box.
> 
> Not all ISPs are that clueful, so it's hard to say exactly what you
> (or any other user) might have to deal with.
> 
> > The question still remains:
> >   would you expect a 'normal' [designed for Winxx consumer market]
> > ISP to decode "%40" to "@" as part of the UserId ?
> 
> No, I wouldn't expect that at all.  It sounds like a very strange
> expectation indeed.
> 
> It'd be possible, but highly improbable.  There seems to be no reason
> at all to do this -- other than the apparent fact that you have a
> broken dialer.  ISPs don't really care whether your non-Windows dialer
> is broken.  :-/

---------   end of extract.
Using old DOS BBS software I was able to manually login but not
use the "%40" substitute for the "@" in my ISP-allocated ID.
AFTER login the ISP expected ppp-mode.

This 'text-mode' log-in happened apparently because the ISP
didn't detect 'ppp-mode'.

OTOH when I logged in via linux, the communication was 'in-ppp'
before the UserID [containing the "@"] was given. Apparently this is the
normal mode -- as per 'Windowsxx'.

In both cases the login routines did not decode "%40" to "@".
And James Carlson sees no reason why they should.  Nor do I.

== Chris Glur.