headers
Kevin Kress | 15 Sep 2002 08:43

Aborting SASL authentication from the client

I was hoping the group could clarify something for me.  In SASL when a
client aborts a SASL transaction, sending a <blob status='abort'/> what
would the proper response from the server be?  

Should it respond with a RLY message of "<ok/>"  or perhaps a RLY with
"<error code='451'/>" or should it be the "<error code='451'/>" in a ERR
message?  Other suggestions?

Thoughts?

--Kevin Kress
Permalink | Reply | 1 comment |
headers
Marshall Rose | 15 Sep 2002 20:23
Picon
Picon

Re: Aborting SASL authentication from the client

the server should send

    <blob status='complete' />

which is its way of telling the client that the sasl exchange has
successfully completed. (note that "a successful completion of the
exchange" doesn't mean that the client got authenticated).

/mtr
Permalink | Reply | 0 comments |
headers
Eamon O'Tuathail | 23 Sep 2002 17:53

MIME-Version Header Field

Do BEEP messages require the MIME-Version header field?

RFC 2045 states:

 "Messages composed in accordance with this document MUST include such
  a header field, with the following verbatim text:

     MIME-Version: 1.0"

As BEEP carries MIME messages, one could argue that MIME-Version is a
mandatory header. 

However, the main practical purpose of this header is to tell a RFC
(2)822 user agent that the message they receive is MIME or not - as BEEP
messages are always MIME, it is not needed (unless someone decides to
invent a new version of MIME, which seems unlikely for the near future).

Eamon
Permalink | Reply | 12 comments |
headers
Jered Floyd | 23 Sep 2002 19:00
Favicon

Re: MIME-Version Header Field

"Eamon O'Tuathail" <eamon.otuathail <at> clipcode.com> writes:

> Do BEEP messages require the MIME-Version header field?
> 
> RFC 2045 states:
> 
>  "Messages composed in accordance with this document MUST include such
>   a header field, with the following verbatim text:
> 
>      MIME-Version: 1.0"
> 
> As BEEP carries MIME messages, one could argue that MIME-Version is a
> mandatory header. 

(For those playing along with the home game, this is RFC 2045 
Section 4, "MIME-Version Header Field".)

I interpret the "Messages" in the quoted sentence to mean "RFC 822
messages", since this RFC is all w.r.t Internet message bodies.
While BEEP messages are structured according to the rules of MIME,
I don't consider them to be RFC 2045's "Internet message bodies"
and thus are exempt from needing the MIME-Version header.

All existing specifications and implementations of which I am aware
do not use the MIME-Version header.

--Jered
Permalink | Reply | 1 comment |
headers
Dave Crocker | 23 Sep 2002 19:19

Re: MIME-Version Header Field

At 04:53 PM 9/23/2002 +0100, Eamon O'Tuathail wrote:
>However, the main practical purpose of this header is to tell a RFC
>(2)822 user agent that the message they receive is MIME or not - as BEEP
>messages are always MIME, it is not needed

however, leaving it out violates the specification.

information redundancy does not make things stop working.  violating a 
specification does.

d/

----------
Dave Crocker <mailto:dave <at> tribalwise.com>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850
Permalink | Reply | 1 comment |
headers
Marshall Rose | 23 Sep 2002 20:00
Picon
Picon

Re: MIME-Version Header Field

> however, leaving it out violates the specification.
> 
> information redundancy does not make things stop working.  violating a 
> specification does.

then there's the "be liberal in what you expect and conservative in what you generate" thing.
conservatisms says you should always send it. liberalism says you should never care whether you receive it...

/mtr

ps: it's easy enough for me to add the one line to my implementation to generate it. i don't think i'm going to
be modifying the mime package that i'm using to actually require it though...

/mtr
Permalink | Reply | 0 comments |
headers
Eamon O'Tuathail | 23 Sep 2002 21:50

MIME-Version Header Field


> however, leaving it out violates the specification.

I would agree with that - RFC 2045 says "MUST include such a header
field" (that's not a MAY or a SHOULD), so it MUST be present in the
outgoing BEEP message a peer sends and MUST be verified to be present in
the incoming BEEP message a peer receives. 

However, if a BEEP implementation did this, it would currently
interoperate with no peer that is based on any existing BEEP
implementation - none of them use it! 

I see three possible solutions:

Solution 1) A BEEP implementation adds MIME-Version Header to all
outgoing messages, and does not accept any incoming messages without it
- a strict reading of the MIME and BEEP specs would mandate this. The
first message a peer will receive will be the greeting message on
channel zero, and RFC 3080 says "If a poorly-formed reply is received on
channel zero, the session is terminated without generating a response,
and it is recommended that a diagnostic entry be logged."

Solution 2) A BEEP implementation provides a (locally defined)
configuration option that specifies whether to add MIME-Version headers
on outgoing messages, and another configuration option that states
whether to REQUIRE it on incoming messages.  

Solution 3) That the MIME-Version header be added without changing any
of the implementations - the only way to do this is that in some future
revision, section 2.2. of RFC 3080 be updated with one line about the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jered Floyd | 23 Sep 2002 23:18
Favicon

Re: MIME-Version Header Field


> Solution 3) That the MIME-Version header be added without changing any
> of the implementations - the only way to do this is that in some future
> revision, section 2.2. of RFC 3080 be updated with one line about the
> MIME-Header:
> "2.2 Messages and Frames
>    A message is structured according to the rules of MIME.  Accordingly,
>    each message may begin with "entity-headers" (c.f., MIME's Section 3
>    [1]).  If none, or only some, of the "entity-headers" are present:
>    o  the default "Content-Type" is "application/octet-stream"; and,
>    o  the default "Content-Transfer-Encoding" is "binary".   
>    o  the default "MIME-Version" is "1.0"."  <<<---------------- new
> line
> 
> I would favour option 3. Is that acceptable to others?

This seems like a fine solution.

--Jered
Permalink | Reply | 0 comments |
headers
ned.freed | 23 Sep 2002 23:23

Re: MIME-Version Header Field

> Do BEEP messages require the MIME-Version header field?

> RFC 2045 states:

>  "Messages composed in accordance with this document MUST include such
>   a header field, with the following verbatim text:

>      MIME-Version: 1.0"

> As BEEP carries MIME messages, one could argue that MIME-Version is a
> mandatory header.

This is quite true, however, you've missed a crucial definition: When RFC 2045
talks about "messages" it is talking about RFC 822 messages specifically. This
is clearly stated in section 2.3.

I don't believe it is the case that BEEP is defined to carry RFC 822 messages,
so I don't believe this requirement applies to BEEP.

> However, the main practical purpose of this header is to tell a RFC
> (2)822 user agent that the message they receive is MIME or not - as BEEP
> messages are always MIME, it is not needed (unless someone decides to
> invent a new version of MIME, which seems unlikely for the near future).

It isn't the main practical purpose of the header; it is the only purpose.

I should also point out that we have plenty of examples of protocols, including
some that deal with "messages", which use MIME labelling and do not see a need
to use a MIME-Version field. The obvious example here is HTTP.
(Continue reading)

Permalink | Reply | 5 comments |
headers
ned.freed | 23 Sep 2002 23:36

Re: MIME-Version Header Field

> "Eamon O'Tuathail" <eamon.otuathail <at> clipcode.com> writes:

> > Do BEEP messages require the MIME-Version header field?
> >
> > RFC 2045 states:
> >
> >  "Messages composed in accordance with this document MUST include such
> >   a header field, with the following verbatim text:
> >
> >      MIME-Version: 1.0"
> >
> > As BEEP carries MIME messages, one could argue that MIME-Version is a
> > mandatory header.

> (For those playing along with the home game, this is RFC 2045
> Section 4, "MIME-Version Header Field".)

> I interpret the "Messages" in the quoted sentence to mean "RFC 822
> messages", since this RFC is all w.r.t Internet message bodies.
> While BEEP messages are structured according to the rules of MIME,
> I don't consider them to be RFC 2045's "Internet message bodies"
> and thus are exempt from needing the MIME-Version header.

Exactly right and even supported by a careful reading of RFC 2045.

				Ned
Permalink | Reply | 0 comments |

Gmane