Subject: Pending changes to the base SASL document

From: Alexey Melnikov <[email-masked]>
Date: Wed, 19 May 2004 22:00:57 +0100

I am waiting for resolution on one final issue before issuing a new 
revision of rfc2222bis that should be ready for Last Call.
Plus I have 2 minor new issues with suggested text.

1).
 empty versa missing additional data with success (text in 2 places).

Add to Section 4. ("Protocol profile requirements"):

"Note that SASL treats an empty additional data with success 
notification as equivalent to no additional data with success notification.
If the protocol allows for the additional data with success 
notification, the empty additional data SHOULD NOT be used, unless 
dictated otherwise by the protocol profile."

I am actually not sure myself about the last sentence. Should the 
document just say that an empty additional data with success is prohibited?

Add to Section 5. ("Mechanism profile guidelines"):

"As SASL treats an empty additional data with success notification as 
equivalent to no additional data with success notification, mechanisms 
that may distinguish between no additional data and empty additional 
data MUST use some encoding or escape mechanism when sending data 
semantically equivalent to the empty additional data with success."

The last sentence is awkward at best, any suggestions would be 
appreciated. Currently there is no SASL mechanism that make such 
distinction, but, IMHO, the warning should be added.

=====
New issues:

2). Servers need to perform profile specific mapping from a mechanism 
specific authorization identity to profile specific form. The profile 
specific form is used internally by the server (for example for 
logging), but can often be used by the protocol for access control. In 
order for the client to determine the result of any such mapping, the 
protocol should have a command or option to return it to the client. For 
example, LDAP has 2 ways to achieve this: "Who am I" extended operation 
and a control that can request for mapping information to be returned 
upon successful authentication. I felt that this is a feature common to 
all protocols, and thus should be mentions in the base SASL document. 
Kurt suggested the following text for addition to Section 4. ("Protocol 
profile requirements"):

        Where the application-layer protocol does not precisely state
        how identities established through SASL relate to identities
        used elsewhere (e.g., access controls) in the application-layer
        protocol, it may be useful for the application-layer protocol
        to provide a facility which the client may use to discover the
        identity used.

Any objections?

3). Some people are complaining that some SASL mechanisms use too many 
roundtrips. This is a performance penalty for protocols like HTTP, where 
the client can reconnect multiple times. Currently only DIGEST-MD5 and 
SRP have support for fast reautentication. So, I would like to add the 
following requirement to Section 5. ("Mechanism profile guidelines"). 
Please, let me know if you agree or disagree.
Suggested text:

  "SASL mechanisms SHOULD support fast reauthentication, if practical."

Alexey

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 20 May 2004 12:42:06 -0400 (EDT)

On Wed, 19 May 2004, Alexey Melnikov wrote:

> roundtrips. This is a performance penalty for protocols like HTTP, where the 
> client can reconnect multiple times. Currently only DIGEST-MD5 and SRP have 
> support for fast reautentication. So, I would like to add the following 
> requirement to Section 5. ("Mechanism profile guidelines"). Please, let me 
> know if you agree or disagree.
> Suggested text:
>

Given our limited experience with actual deployment of fast 
reauthentication mechanisms (Has anyone actually tested any sort of 
interoperability of DIGEST-MD5 fast reauth?), I wouldn't want us to give 
the impression that a mechanism that does not support fast 
reauthentication is somehow less than fully compliant (yeah, ok, it is 
only a SHOULD).

If there's a demand for mechanisms that support fast reauth, then those 
mechanisms will be written and implemented widely.  Currently, that isn't 
the case, and I don't see a reason why the base document needs to pass 
judgment on the matter.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 May 2004 14:05:17 -0400

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey>   "SASL mechanisms SHOULD support fast reauthentication,
    Alexey> if practical."

    Alexey> Alexey

I don't like this text because it is not even clear what it means.

How about:

SASL mechanisms should be designed to minimize the number of round
trips required because SASL is used with protocols where connections
are short-lived.

As a side note, has thought been given in the HTTP case to having
mechanisms for reusing SASL contexts across connections?

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 May 2004 21:48:42 +0100

>trips required because SASL is used with protocols where connections
Ok, that sounds better. But I will change "SASL is used" to "SASL may be 
used".

>mechanisms for reusing SASL contexts across connections?
Well, I thought about that, this is one of the reasons why I've proposed 
that the sentence is added. But I am not sure I have a firm opinion on 
how this will be done.

IMHO, DIGEST-MD5 fast reauth mode can be used accross multiple 
connections, because the client IP is not used in the authentication 
exchange.

I am also contemplating about writing an extension to the GSSAPI 
mechanism to allow for fast reauth in  1 round trip.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 May 2004 21:40:53 +0100

Rob Siemborski wrote:

>> 3). Some people are complaining that some SASL mechanisms use too 
>> many roundtrips. This is a performance penalty for protocols like 
>> HTTP, where the client can reconnect multiple times. Currently only 
>> DIGEST-MD5 and SRP have support for fast reautentication. So, I would 
>> like to add the following requirement to Section 5. ("Mechanism 
>> profile guidelines"). Please, let me know if you agree or disagree.
>> Suggested text:
>>
> interoperability of DIGEST-MD5 fast reauth?), I wouldn't want us to 
> give the impression that a mechanism that does not support fast 
> If there's a demand for mechanisms that support fast reauth, then 
> those mechanisms will be written and implemented widely.  Currently, 
> that isn't the case, and I don't see a reason why the base document 
> needs to pass judgment on the matter.

Ok, this is a fair argument against the suggested text.

Alexey

P.S. You haven't answered the most difficult question (# 1). As you are 
the one who has raised the original objection, I would like to hear your 
comments.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 May 2004 09:04:10 -0400

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:
    Alexey> I am also contemplating about writing an extension to the
    Alexey> GSSAPI mechanism to allow for fast reauth in 1 round trip.

I believe you can just remove a half round trip from the GSSAPI all
the time by combining the security layer stuff with the last token.

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 09:35:05 -0400 (EDT)

> trips required because SASL is used with protocols where connections

I like this text more (especially the use of 'should' instead of SHOULD), 
but I'm still unclear why the base document needs to say anything at all 
about it.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 09:39:07 -0400 (EDT)

On Thu, 20 May 2004, Alexey Melnikov wrote:

> P.S. You haven't answered the most difficult question (# 1). As you are the 
> one who has raised the original objection, I would like to hear your 
> comments.

Do we really need to make lack-of-response equivilent with the empty 
response?  It seems we can handle this cleanly enough if we treat it 
just like the initial response.

e.g.

If the protocol allows for the initial response, the
protocol profile SHOULD also describe how an empty initial response
is encoded.

could be worded as

If the protocol allows for optional data to be sent with success 
notifiation, the protocol profile SHOULD also describe how empty 
success data is encoded.

later on in Section 4.

Forbidding empty success data makes me less happy (its less flexible), but 
I think its better than defining "no data" as equivilent to "the empty 
string was sent".

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 May 2004 15:08:45 +0100

>the time by combining the security layer stuff with the last token.
That would be fine, unfortunately this is not a backward compatible 
change to the GSSAPI mechanism. When we get to discussing the GSSAPI 
draft, we can talk about this.

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 May 2004 16:21:47 +0100

Rob Siemborski wrote:

>> P.S. You haven't answered the most difficult question (# 1). As you 
>> are the one who has raised the original objection, I would like to 
>> hear your comments.
>
> Do we really need to make lack-of-response equivalent with the empty 
> response?

Maybe we don't. But some of the existing LDAP implementations treat 
missing additional data as no data, and some that treat missing 
additional data as empty data. There is an interoperability problem here.

>   It seems we can handle this cleanly enough if we treat it just like 
> the initial response.
>
> e.g.
>
> notification, the protocol profile SHOULD also describe how empty 
> success data is encoded. 

I thought about that, but all [known to me] protocols that allow for 
additional data with success are able to send an empty additional data. 
So this phrase seems kid of redundant.

> later on in Section 4.
>
> Forbidding empty success data makes me less happy (its less flexible), 
> but I think its better than defining "no data" as equivalent to "the 
> empty string was sent".

Alexey

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 11:40:58 -0400 (EDT)

> So this phrase seems kid of redundant.

Then it should be easy for existing protocols to comply, shouldn't it?

> > but I think its better than defining "no data" as equivalent to "the

If there is a current interop problem with LDAP, this may be the safest
way to go.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 May 2004 10:03:23 -0700

The first part of the problem is that we have some protocols
which allow and distinguish no and empty initial/final data
and some protocols allow either no or empty and treat the
latter as equivalent to no data.

While the obvious "fix" may be to say that no and empty data
are equivalent in the initial response and final challenge,
both meaning no data, that does raise some additional issues.

If the appropriate initial response to a challenge was empty,
the client could not produce that response as an optional
initial response because it no longer distinguishable from
no optional initial response.  Likewise for the optional final
challenge data.

That is, with this change, we need to be clear that the
optional data features are only usable where the data to
be transferred has non-zero length.

Kurt

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 13:11:21 -0400 (EDT)

> be transferred has non-zero length.

I'm pretty sure there are currently deployed clients that use the initial
response with an empty string with EXTERNAL, so I think we need to
continue to encourage protocol profiles to make that distinction.

If we don't want to treat success data the same way, I do think that we
are in a good position to just forbid empty success data outright.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 May 2004 10:48:40 -0700

>be transferred has non-zero length. 

And, we should note that some mechanisms may mandate
use of initial response data (and/or final data).
For instance, EXTERNAL effectively does.  There is no
defined challenge, and even there was, the client's
initial message, when data provided had no length,
would be ambiguous as whether it was providing an
empty authzid or providing no initial data.  So,
with EXTERNAL, initial data is not optional.

Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 May 2004 13:44:13 -0400

> but I'm still unclear why the base document needs to say anything at all

I also like this text more, except the use of 'should' instead of SHOULD. 
Using requirements keywords in lower case is confusing -- a future reader 
will have no way to know in which sense the word was used.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 May 2004 13:54:07 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> I also like this text more, except the use of 'should'
    Jeffrey> instead of SHOULD. Using requirements keywords in lower
    Jeffrey> case is confusing -- a future reader will have no way to
    Jeffrey> know in which sense the word was used.

I did not mean SHOULD.  Assuming the working group believes text in
this area is appropriate, I wouldn't object to rephrasing.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 May 2004 13:59:26 -0400

Alexey> Rob Siemborski wrote:

    >>> P.S. You haven't answered the most difficult question (#
    >>> 1). As you are the one who has raised the original objection,
    >>> I would like to hear your comments.
    >>  Do we really need to make lack-of-response equivalent with the
    >> empty response?

    Alexey> Maybe we don't. But some of the existing LDAP
    Alexey> implementations treat missing additional data as no data,
    Alexey> and some that treat missing additional data as empty
    Alexey> data. There is an interoperability problem here.

    >> It seems we can handle this cleanly enough if we treat it just
    >> like the initial response.

But is it worth the complexity?  IT seems that if we can avoid the
introduction of distinguishing the two cases we should do so.

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 13:55:08 -0400 (EDT)

> with EXTERNAL, initial data is not optional.

This is precisely why protocols profiles need to provide "how do I send an
empty challenge" information.

Saying EXTERNAL makes initial data mandatory leads to ambiguity,
especially with a protocol that was originally designed without an initial
response, but later one is added via capability (e.g.
draft-siemborski-imap-sasl-initial-response).

In this case, the (new) server can only determine if the client
is old-style or new-style based on if the client explicitly transmits an
empty string with the initial response.  Otherwise, the server *has* to
assume that the client is old-style, and treat it accordingly.

If "initial response is mandatory for EXTERNAL" the server can no longer
make this determination.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 13:59:20 -0400 (EDT)

> this area is appropriate, I wouldn't object to rephrasing.

Text in this area may be appropriate, but it seems like it opens the door
to recommendations like:

"SASL may be used on low bandwidth devices, thus mechanisms should[SHOULD]
use as few octets as possible in their challenges and responses"

"SASL may be used over high-latency links or users who type passwords
slowly, thus mechanisms should[SHOULD] not be susceptible to long delays
between challenges and responses"

Reducing the number of round trips is indeed a noble engineering goal,
but is this really a *requirement* that the base document needs to
specify, or is it just good engineering practice that we can assume that
the future mechanism authors will address?

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 14:01:36 -0400 (EDT)

> introduction of distinguishing the two cases we should do so.

If it is not worth the complexity (and, really, I can't think of any
situation where an empty server success data would be *useful*-- it just
seems that we'd be giving up some level of flexability), then we should
just forbid empty success data -- this would lead to the less confusion
than attributing two potential meanings to "no success data".

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 14:14:41 -0400 (EDT)

On Fri, 21 May 2004, Kurt D. Zeilenga wrote:

> The problem is that RFC 2222 was terrible clear as to who the option
> for initial/final data belongs to.  It seems clear that we have some
> mechanisms designers who treated it as their option and some protocol
> designers who treated it as their option.  So, who's option is it?

My interpretation of 2222 was that:

* it was optional for a protocol profile to support the capability
* it was optional for a mechanism to support the capabilitiy (e.g. the
   server might always have to send first, thus no matter what you do you
   cannot use an initial client send with this mechanism)
* it was optional for the client to choose to use the capability, even if
   the above two were true.

So, I'd answer your question as "it's everyone's option except the 
server's" -- or rather, any one of (mechanism, protocol, client) can 
choose not to use the initial response for whatever reason they deem 
appropriate.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 May 2004 11:11:11 -0700

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 May 2004 11:35:53 -0700

>* it was optional for the client to choose to use the capability, even if

The problem I have with your interpretation is that it
implies that in all cases that the client always has
the option to not to provide an initial response.
However, RFC2222 clearly didn't provide this option
in EXTERNAL.  RFC 2222 was reasonable clear that an no
initial response data was equivalent to empty initial
response data in regards to EXTERNAL (see examples).

Kurt

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 14:41:44 -0400 (EDT)

On Fri, 21 May 2004, Kurt D. Zeilenga wrote:

> response data in regards to EXTERNAL

How so?  RFC2222 states:

5.1.  Client sends data first

    ...

    If the initial client response parameter is not given, or if a
    protocol's profile does not permit the command which initiates an
    authentication protocol exchange to contain an initial client
    response, then the server issues a challenge with no data.  The
    client's response to this challenge is then used as the initial
    client response.

    ...

It also states:

7.4.  External mechanism

    ...

    The client sends an initial response with the authorization identity.

    ...

Based on section 5.1, "initial response" could be either sent with the 
SASL initiation command *or* after the server sends the blank challenge.

> (see examples).

There are no examples for EXTERNAL in RFC2222, and even if there were, 
they'd only be in IMAP without the SASL-IR extension, so this wouldn't 
matter anyway.

I don't see any requirement here that EXTERNAL MUST use the initial 
client response parameter.  Am I missing something obvious here?

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 May 2004 11:38:57 -0700

>this area is appropriate, I wouldn't object to rephrasing.

I prefer "should".  I view the suggested text as stating a
consideration not a requirement.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 May 2004 12:09:08 -0700

>   The client sends an initial response with the authorization identity.

Note that it does not say:
        The client may optionally send an initial response with the authorization
        identity.

And, if the client were not to send an initial response, there is no
specified challedge for the server to issue to obtain the authorization
identity.

>Based on section 5.1, "initial response" could be either sent with the SASL initiation command *or* after the server sends the blank challenge.

Okay, but see below.

>>(see examples).

Sorry, I was looking at 2222bis when I made that comment.

>I don't see any requirement here that EXTERNAL MUST use the initial client response parameter.  Am I missing something obvious here?

I am under (maybe a false impression) that there are protocols
in existence which do not distinguish no initial data from empty
initial data, as well as there being protocols which do not
distinguish no final data from empty final data.  If such
protocols do exist, then we deal with them somehow.

I would agree that a requirement that all protocols must
distinguish between no and empty initial/final data would
effectively resolve the problem, but it would break any
protocol which doesn't distinguish these cases today.

Kurt

---

From: Ken Murchison <[email-masked]>
Date: Fri, 21 May 2004 16:11:34 -0400

> specified challedge for the server to issue to obtain the authorization

I think the problem here is that the EXTERNAL spec uses the term 
"initial response" which is implying that the response can only be sent 
with the command which starts the authentication.  My understanding is 
that EXTERNAL consists of a single message sent from client to server 
which contains the authzid.  If the protocol profile allows for an 
initial response and the client chooses to do so, then the authzid MAY 
be sent as an initial response.  Otherwise, the server will send an 
empty challenge to prompt the client for the authzid.  Either way, the 
client MUST provide an authzid.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 16:21:15 -0400 (EDT)

> specified challedge for the server to issue to obtain the authorization

There doesn't need to be -- section 5.1 speaks to how you handle this case 
-- are you saying you can't use EXTERNAL if the protocol does not support 
an initial response argument?

> protocols do exist, then we deal with them somehow.

At the very least, SMTP and POP's current protocol profiles are poorly 
worded and have led to interoperability problems in this area, yes.

> protocol which doesn't distinguish these cases today.

This would not be the first thing that 2222bis would "break" -- indeed, 
it removes ambiguity, in much the same way that forcing the use of 
SASLprep may cause new clients to not work with older servers..

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Ken Murchison <[email-masked]>
Date: Fri, 21 May 2004 16:38:36 -0400

> client MUST provide an authzid.

I should have added the following to my last sentence: "which may be empty".

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 May 2004 17:20:01 -0400

>>>>> "Rob" == Rob Siemborski <[email-masked]> writes:

    >> designers who treated it as their option.  So, who's option is it?

    Rob> My interpretation of 2222 was that:

    Rob> * it was optional for a protocol profile to support the capability
    Rob> * it was optional for a mechanism to support the capabilitiy (e.g. the
    Rob>    server might always have to send first, thus no matter what you do you
    Rob>    cannot use an initial client send with this mechanism)
    Rob> * it was optional for the client to choose to use the capability, even if
    Rob>    the above two were true.

This seems like horrible protocol design in that it creates too many
options and I'm unclear there is a need for all these options to
exist.

There may not be much we can do about it for backward compatibility
reasons.  However it seems like we should at least ask ourselves what
we can do to simplify things while meeting our interoperability
requirements.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 23 May 2004 23:41:52 +0100

>consideration not a requirement.
That is correct. The whole section 5 is [mostly] about considerations.

Alexey

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 24 May 2004 12:25:52 -0400

> this area is appropriate, I wouldn't object to rephrasing.

I suppose I should clarify my comment.  I didn't think you meant SHOULD, 
and I agree -- lacking a security or interoperability reason the use of 
SHOULD here would be questionable.  For the record, I do think providing 
advice to mechanism designers is a good idea, and I have no objection to 
text in this particular area.

-- Jeff

---

From: Rob Siemborski <[email-masked]>
Date: Thu, 20 May 2004 12:42:06 -0400 (EDT)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 May 2004 14:05:17 -0400

Alexey> Alexey

How about:

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 May 2004 21:48:42 +0100

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 May 2004 21:40:53 +0100

Alexey

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 May 2004 09:04:10 -0400

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 09:35:05 -0400 (EDT)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 09:39:07 -0400 (EDT)

e.g.

could be worded as

later on in Section 4.

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 May 2004 15:08:45 +0100

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 May 2004 16:21:47 +0100

Alexey

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 11:40:58 -0400 (EDT)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 May 2004 10:03:23 -0700

Kurt

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 13:11:21 -0400 (EDT)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 May 2004 10:48:40 -0700

Kurt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 May 2004 13:44:13 -0400

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 May 2004 13:54:07 -0400

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 May 2004 13:59:26 -0400

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 13:55:08 -0400 (EDT)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 13:59:20 -0400 (EDT)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 14:01:36 -0400 (EDT)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 14:14:41 -0400 (EDT)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 May 2004 11:11:11 -0700

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 May 2004 11:35:53 -0700

Kurt

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 14:41:44 -0400 (EDT)

How so?  RFC2222 states:

    ...

    ...

It also states:

7.4.  External mechanism

    ...

    ...

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 May 2004 11:38:57 -0700

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 21 May 2004 12:09:08 -0700

Okay, but see below.

Kurt

---

From: Ken Murchison <[email-masked]>
Date: Fri, 21 May 2004 16:11:34 -0400

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 21 May 2004 16:21:15 -0400 (EDT)

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

---

From: Ken Murchison <[email-masked]>
Date: Fri, 21 May 2004 16:38:36 -0400

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 May 2004 17:20:01 -0400

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 23 May 2004 23:41:52 +0100

Alexey

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 24 May 2004 12:25:52 -0400

-- Jeff