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

> not@top-post writes:
> > Please help resolve this 'argument' :--
>
James Carlson <(E-Mail Removed)> wrote:
> The argument looks a bit bizarre to me.
>
> > No ! When the ISP is logging-in it doesn't know about 'W3C encoding'.
> > Until login & password stage is completed, ppp is not used.
> > So the 'fancy stuff' of W3C encoding is not possible.
>
> I have no idea what that's about.
>
> PPP does have authentication built into it, and it does involve what
> is essentially a login. I cannot tell what that text above is talking
> about, though.
>
> W3C encoding has _nothing_ to do with PPP, unless some ISP has a
> convention using it. Such conventions are entirely outside the
> standards -- not prohibited by it, but not documented either.
>
> > No !! Would you also try to 'escape' the "3" in the tone-dialling
> > with a %51 ?!
> > ---------------
> > Am I wrong, or how else can I word it so that they understand ?
>
> This is lacking so much context that I don't think anyone can give you
> a good answer.
>
> Why would W3C %XX encoding have anything to do with it? What does
> Oberon have to do with PPP? What exactly are you trying to do? What
> problem is it you're trying to solve?
>
Try to 'think out of the box' please !
Persons who know about ppp MUST know about dial-in ISPs.
And they know that eg. character "@" can be decoded to %40
via some inet convention [RFC standard].

The question reduces to:
is this decoding available before login.
I.e. before the UserID and password have been accepted ?

I say no.
The sequence is aproximately as follows:
1. ISP modem receives a 'call' & dialogs with the caller in 'plain serial
ASCII', with no '%XX encoding' ability.
2. Only if the UserID and password stage are passed does ppp become
enabled. So apparently ppp also doesn't do '%XX encoding'.
3. Then an even later stage must do the '%XX encoding' ?

Conclusion:
the "@" character in the userID or password can't be '%XX encoded'
because at that stage the ISP doesn't understand '%XX encoding'.

== Chris Glur.





not@top-post

not@top-post writes:
> Try to 'think out of the box' please !

The problem is that I'm not sure what box you're stuck in.

> Persons who know about ppp MUST know about dial-in ISPs.

Sure.

> And they know that eg. character "@" can be decoded to %40
> via some inet convention [RFC standard].

Absolutely.

> The question reduces to:
> is this decoding available before login.
> I.e. before the UserID and password have been accepted ?

The question makes no sense to me.

The answer depends entirely on local conventions and what the
authentication software and ISP chooses to do. It's not at all
governed by anything in the PPP standards. It's an implementation
issue.

In other words, if a vendor of PPP or authentication software wants to
support such a thing, that's fine. If an ISP wants to deploy it,
that's also fine. It has nothing to do with what is "available."

(By saying "available," it sounds to me like you're making some sort
of assumptions about how the software is built internally, and what
the software can and cannot do. I don't understand those
assumptions.)

> I say no.
> The sequence is aproximately as follows:
> 1. ISP modem receives a 'call' & dialogs with the caller in 'plain serial
> ASCII', with no '%XX encoding' ability.

Actually, that's not quite true on at least three counts:

- Most modern ISPs launch PPP immediately on dial-in. There's no
plain old ASCII conversation anymore, as such conversations
require extensive scripting on the caller's side, and are hard (or
impossible) to support with ordinary Windows users (unfortunately
the bulk of the clientele).

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

- 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 "(E-Mail Removed)". Otherwise, you'll
just need to find a new ISP.

In fact, I think that the idea of using %XX encoding inside of peer
names used for PPP authentication would be particularly crack-headed,
but my opinion rarely stops others from doing what they please. ;-}

> 2. Only if the UserID and password stage are passed does ppp become
> enabled. So apparently ppp also doesn't do '%XX encoding'.

This assumption isn't correct.

For most modern ISPs, PPP typically starts immediately. It then
negotiates LCP (link parameters), and then uses either PAP (simple
username / password) or CHAP (challenge / response) to authenticate
the user. The authentication takes place *within* PPP, not outside of
it.

There are still a few 'unusual' ISPs that require a text-based login
before starting PPP. They're by far the minority, because it's hard
to tell a Windows user how to interact with such a thing. (And some
of those repeat the same authentication in PPP afterwards.)

Even in the cases where text-based login is used, there's nothing that
prohibits anyone from using %XX if they want to. Again, I've never
heard of such a thing ever being done for any reason (why on earth
would you want it?), but that alone doesn't make it impossible.

> 3. Then an even later stage must do the '%XX encoding' ?
>
> Conclusion:
> the "@" character in the userID or password can't be '%XX encoded'
> because at that stage the ISP doesn't understand '%XX encoding'.

The conclusion isn't really based on anything useful.

The real issue here is what the authenticator _requires_ the
authenticatee to do to prove his identity. Authenticators are
generally free to demand whatever they want of authenticatees. It's
the authenticatee who is on the hook to provide it (or look elsewhere
for service).

Let me try to explain this another way, by getting away from the
apparently hot topic of %XX encoding. Some ISPs today (but not all)
require users to express their identity as "(E-Mail Removed)".
Internally, the ISP breaks this apart at the "@" sign, and uses
"domain.tld" to select a back-end authentication server. This allows
the ISP to serve multiple populations of users.

RFC 2486 documents that usage, and it's probably a good one, but
nothing actually _compels_ it. ISPs are free to require what they
want from their users. Some may ask for just "user", and others may
ask for a completely different format.

Similarly, ISPs are free to just treat the entire "(E-Mail Removed)" as
a single token -- not breaking it apart at the "@" sign -- and
authenticate with a unified database. There's really no way an user
could tell which of these is done.

Would we assert that the "(E-Mail Removed)" encoding has to be
"available" (whatever that might mean) at authentication time? No, of
course not. We merely assert that a user who wants to talk to one of
those systems configured to use that encoding will need to express his
identity in those terms. How he accomplishes that (by explicit
configuration or by some special encoding software) is completely out
of scope, as it's his problem to solve.

(And what did Oberon have to do with the question ... ?)

--
James Carlson, IP Systems Group <(E-Mail Removed)>
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