Subject: [midcom] STUN issue 1: response codes

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Nov 2002 02:38:11 -0500

Folks,

As Melinda pointed out, there were several comments from IESG that 
require fixing in STUN. A few probably merit group discussion. I will be 
sending a separate email on each of those, proposing my solution, and 
will also discuss tomorrow.

The first issue is response code handling. STUN specifies a new 
structure, using explicitly defined class and code values. This is 
similar to, but deviates from, more conventional three-digit reporting 
used in SMTP, SIP, HTTP and others. The IESG comment was that we should 
align here.

I am inclined to agree. So, I propose we revert to a standard three 
digit code, and define the specific 400 class response codes we need. We 
also define the 500 class, but don't populate it with any respaonse 
codes, for potential future use. We ignore the 300 and 600 classes, as 
they are not applicable to STUN (anywya the usage of 300 class responses 
differs between SMTP and SIP/HTTP, so best to stay away from that...)

Anyone object?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 19 Nov 2002 11:13:26 -0000

I agree the IESG's proposal that the codes should be broken down into what
should happen next (e.g. retry, give up etc) rather than what caused them.

However, as STUN is binary and SMTP etc are text, I don't think this implies
that they need to use the regular text based 3 digit code.  (The format is
really already aligned, but just uses a more binary friendly base 256
instead of base 10.)

From a debug point of view, it's probably easier for someone to look at the
current class based scheme rather than having to work out that 0x1A4 is a
class 400 error.  (I would prefer to see the class codes divided by 100,
e.g. 400 -> 4, 500 -> 5 etc.)

Still, dividing by 10 is no great hardship nowadays, so if it keeps people
happy, it's OK by me.

Pete.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Nov 2002 03:30:02 -0500

We discussed this during the midcom meeting. There was support for using 
the more traditional three digit response code. Also, Eliott Lear had 
made some comments which, at the time I didn't understand, but 
afterwards, figured out that he didn't want a textual encoding, as you 
are suggesting, Pete.

A middle ground approach is to actually use binary coded decimal here. 
That allows you to access the class directly, but requires you to do 
some multiplication and additions to get at an integral representation 
of the response code.

Another approach is to retain a class field (8 bits, but values of 1-6 
only allowed), separate from the actual numeric code (16 bits, but 
values 100-699 only). This is the same number of bits as BCD but 
requires no arithmetic operations. This is consistent with Patrik's 
suggestion to use a three-digit response code, but it merely provides a 
convenient encoding of such a code in a binary protocol. I suspect he 
would be fine with that. I am not sure, Pete, if this is what you were 
effectively saying below about dividing by 100.

So, my current proposal is this class/code mechanism.

Thoughts?

-Jonathan R.

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 21 Nov 2002 10:40:33 -0000

Jonathan,

My main concern is that it doesn't take on a split personality between a
binary and text protocol which I think would lead to confusion among
implementers.

I almost like your suggestion, but I would make the range of the numeric
code only 00-99 so that both the class and numeric value were needed to work
out the actual error.

Iterating a few times, I end up with:

- a class field (3 bits, values of 1-6 only allowed),
- separate per class numeric code 8 bits, but values 00-99 only.

encoded something like:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   0                     |Class|     Number    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Reason Phrase (variable)                                ..
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This avoids duplication of the class in the numeric value (which would be
another source of confusion), and is very close to in philosophy to the 3
digit error code, but is still binary.

Pete.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Nov 2002 13:03:02 -0500

> code only 00-99 so that both the class and numeric value were needed to work

I thought about this; the main problem is that it will probably require 
a multiply-by-10 to get the complete response code. Now, that certainly 
depends on implementation, since you could keep them separate throughout 
the code..

> - separate per class numeric code 8 bits, but values 00-99 only.

I don't feel strongly, really, and could go either way. I will use your 
suggestion unless anyone has further comment.

-Jonathan R.

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 25 Nov 2002 17:50:14 -0000

please see comments inline...

Pete

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Pete Cordell" <[email-masked]>
Cc: <[email-masked]>
Sent: 21 November 2002 18:03
Subject: Re: [midcom] STUN issue 1: response codes

> depends on implementation, since you could keep them separate throughout

To get the complete code you would just operate on the entire 11 bits (3+8)
of the error code.  (This is an extra bit over what you'd need to encode 699
in binary - 1010111011 - but this is no issue.)

error_class = ( error_word & 0x700 ) >> 8;
per_class_error = error_word & 0xff;

But this is not really the issue as any device that is likely to use STUN
will won't have any problems handling division by 100 etc, which would
be required if it was a pure decimal number.

The real benefit is avoiding producing a schizophrenic protocol that is
mostly binary, but has a little text for no good reason.  That would lead to
confusion amongst implementers and therefore interoperability problems.