Subject: [midcom] STUN extensibility

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Dec 2002 09:40:12 -0500

Folks,

I was in the process of updating STUN based on list consensus on the 
issues raised by IESG. Many of them surrounded STUN extensibility. While 
working through the draft, I noted there were some additional issues 
(new message types can be defined, but no backwards compatibility 
negotiation defined). I think its worth getting agreement on a specific 
extensibility strategy and then making everything consistent with that.

Generally, I think we have minimal need for extensibility. We should 
focus on simplicity, and not make this as complex or powerful as SIPs 
capabilities.

There are several things which are potentially extensible:

* new message types
* new flags
* new attributes
* new error codes
* new address families

We really don't need built in extensibility and backwards compatibility 
for all of these. I believe that new attributes are the primary area 
where we want to make sure we can be extensible. I do not believe we 
need new message types or new flags (after all, anything you can do with 
a flag you could also do with a new attribute). So, I would like to 
reverse our decision on flags (open issue #3) and simply declare them 
non-extensible. Also, there is text which states that message types can 
be added by standards track RFCs, and I would like to remove that text too.

That leaves attributes, error codes and address families. For 
attributes, I believe that the current text plus the proposed resolution 
to open issue #2 (for which there were no comments) is sufficient. That 
is, extensions documented in standards track RFCs can define new 
attributes, and we will add the 420/Unsupported mechanism as proposed.

For error codes, I believe the text as it stands is fine (unknown error 
codes are treated like the x00 request). The only thing to add is that 
new codes can be defined in standards track RFCs.

For address families, I believe we had consensus to remove support for 
new address families (only v4 is defined), but to keep the existing 
syntax which has an explicit family. [I will make a side note that I've 
recently been working on IPv4/IPv6 transition mechanisms which can 
benefit from STUN and would require v6 addresses, but we can always deal 
with that by revving stun if needed].

Thanks,
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