Re: dail-up ISP login can't do W3C encoding. - PPP

This is a discussion on Re: dail-up ISP login can't do W3C encoding. - PPP ; To: Subject: %XX/W3C-encoding not applicable to ISP login 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: dail-up ISP login can't do W3C encoding.

  1. Re: dail-up ISP login can't do W3C encoding.

    To:
    Subject: %XX/W3C-encoding not applicable to ISP login


    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
    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@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 '
    > > 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.


  2. Re: dail-up ISP login can't do W3C encoding.

    not@top-post writes:

    >To:
    >Subject: %XX/W3C-encoding not applicable to ISP login



    >I hope this finally puts this argument to rest.


    Only one comment. If your dialer uses the @ as a special character, then it
    should also provide a way of escaping that special use. Otherwise it is a
    badly written dialer. That is of course possible, but it is also possible
    that they do provide an escape. It is very strange if it does use @ since
    many many many NT based machines demand user@somewhere as the form of the
    user name. The writers of that dialer must live in a cave if they really do
    that. And no, I certainly would not have expected %40 to translate to @ for
    a login name.



    >1. The ISP allocated me the userID with an embedded "@" char.


    Very common.
    >2. The dialer assumes no userID will contain a "@" char. and uses
    > "@" as the deliniter of the userID.


    Are you sure?

    >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.



    It would be very stupid if they did, just as it would be stupid to assume
    that no userID contains @.

+ Reply to Thread