Subject: Re: [BEHAVE] STUN/TURN "CLIENT" attribute

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Jul 2008 11:12:33 -0400

I've assigned 0x8030.

Thanks,
Jonathan R.

Matthew Kaufman wrote:
> I'm happy to see that there will be a CLIENT attribute to go along with 
> the SERVER one. I was prohibited by company policy from weighing in with 
> my support.
> 
> We've implemented support for TURN in Flash Player 10 (currently in 
> beta), but we're using our own choice for the attribute ID (0x8030) for 
> CLIENT. I haven't been able to find anything with the actual value that 
> will be used... has an assignment been made that I'm just not finding? 
> It'd be nice to have the correct value in the final release.
> 
> Matthew Kaufman
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Sat, 5 Jul 2008 13:08:22 -0400

The text in draft-ietf-behave-rfc3489bis-16, section 7.1 "Forming a  
Request or an Indication" says:

    The agent then adds any attributes specified by the method or the
    usage.  For example, some usages may specify that the agent use an
    authentication method (Section 10) or the FINGERPRINT attribute
    (Section 8).  In addition, the client SHOULD add a CLIENT attribute
    to the message.

Some comments on this:
1) Last fall, the definition of "server" in STUN was changed to allow  
servers to also send indications.

2) Do we want indications to carry CLIENT and SERVER attributes? I  
think we don't want TURN's Send and Data indications to carry these  
attributes, since this would decrease the amount of application data  
that could be carried without exceeding the MTU.

3) The only other use of indications that I can think of off-hand is  
ICE's Binding indications (used for keep-alives)? Should these carry  
one of these attributes? My current opinion is that it wouldn't hurt,  
but it is probably not necessary.
If they do, which should they use: CLIENT or SERVER? To me, CLIENT  
seems the most appropriate.

- Philip

On Wed, 2-Jul-08, at 11:12 , Jonathan Rosenberg wrote:
> I've assigned 0x8030.
>
> Thanks,
> Jonathan R.
>
> Matthew Kaufman wrote:
>> I'm happy to see that there will be a CLIENT attribute to go along  
>> with the SERVER one. I was prohibited by company policy from  
>> weighing in with my support.
>> beta), but we're using our own choice for the attribute ID (0x8030)  
>> for CLIENT. I haven't been able to find anything with the actual  
>> value that will be used... has an assignment been made that I'm  
>> just not finding? It'd be nice to have the correct value in the  
>> final release.
>> Matthew Kaufman

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 6 Jul 2008 18:47:46 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Philip Matthews
> Sent: Saturday, July 05, 2008 10:08 AM
> To: Behave WG
> Subject: Re: [BEHAVE] STUN/TURN "CLIENT" attribute
> 

Perhaps the attribute should just be renamed from CLIENT to
SOFTWARE-IDENTIFIER (or something) and we should dispense with the SERVER
attribute, so that we don't get into this (continual) conundrum of client
versus server?

> that could be carried without exceeding the MTU.

It seems appropriate to discuss this in the TURN specification.

> seems the most appropriate.

I don't see the value of including it with a keepalive -- it only
makes the keepalive bigger.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Jul 2008 14:39:08 -0400

inline:

> attribute, so that we don't get into this (continual) conundrum of client

I think that'll make things more confusing; since now its yet another 
header for declaring software versions thats different from SIP and 
different from the previous spec revision.

Client is pretty well defined in RFC3489bis now, as is server. Both can 
send indications. So depending on what you are, you include the 
appropriate thing.

> It seems appropriate to discuss this in the TURN specification.

I'd suggest that the spec make inclusion of CLIENT/SERVER a SHOULD for 
requests/responses and for indications is MAY. TURN can say, don't bother.

> makes the keepalive bigger.

I don't see value either.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Jul 2008 14:41:32 -0400

OK, here is the text I changed in rfc3489bis:

	  <t>If the agent is a client and is sending a request, it
	  SHOULD add a CLIENT attribute to the request. Agents MAY
	  include a CLIENT or SERVER attribute in indications,
	  depending on the method. For Binding, their usage is NOT
	  RECOMMENDED.
	  </t>

OK?

-Jonathan R.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Jul 2008 11:52:40 -0700

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, July 07, 2008 11:42 AM
> To: Dan Wing
> Cc: 'Philip Matthews'; 'Behave WG'

I would just drop the last sentence, because rfc3489bis only describes the
Binding usage, but there may well be a situation where knowing the client
software version or server software versoin is helpful.  It was the ICE
binding indications (keepalives) that I thought the software information was
not necessary, but ICE's binding indications are discussed in the ICE
document.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Jul 2008 16:47:38 -0400

OK, good point. I'll drop the last sentence. It needs a mention in ICE 
then; I'll add to my auth48 list - this is a small change.

-Jonathan R.

---

From: Philip Matthews <[email-masked]>
Date: Mon, 7 Jul 2008 11:55:48 -0400

> attribute, so that we don't get into this (continual) conundrum of  

This seems like an excellent idea to me. However, I suggest we rename  
the SERVER attribute (since it has been around for some time) instead  
of the CLIENT attribute. To handle Matthew Kaufman, I suggest we mark  
the new CLIENT attribute codepoint as either deprecated or reserved.  
The SERVER attribute is in the comprehension-optional range, so this  
new use should not be a problem.
I feel a bit foolish that we didn't think of this earlier ...

> It seems appropriate to discuss this in the TURN specification.

This was intended to ask whether it was ever appropriate to use these  
in an indication.

For now, I have added text to TURN to say that they are not used in  
Send and Data indications.

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2008 16:51:36 -0400

inline:

Philip Matthews wrote:
> the SERVER attribute (since it has been around for some time) instead of 
> the CLIENT attribute. 

Actually I like this; its backwards compatible with RFC3489.

> To handle Matthew Kaufman, I suggest we mark the 
> new CLIENT attribute codepoint as either deprecated or reserved. The 
> SERVER attribute is in the comprehension-optional range, so this new use 
> should not be a problem.

Well, I am a bit reluctant to reserve codepoints because on a single 
implementation which grabbed something. Seems easier to me to put the 
right thing in the spec and folks can adjust their implementations to 
match. Especially here, where this is a trivial change.

-Jonathan R.

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 08 Jul 2008 13:54:16 -0700

Jonathan Rosenberg wrote:
>
> Philip Matthews wrote:
>
>> To handle Matthew Kaufman, I suggest we mark the new CLIENT attribute 
>> codepoint as either deprecated or reserved. The SERVER attribute is 
>> in the comprehension-optional range, so this new use should not be a 
>> problem.
>
We can change to a different codepoint if we know what it is soon 
(within a few weeks), otherwise a few hundred million copies of code 
implementing the existing value will be out in the field.

Matthew Kaufman

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2008 17:00:20 -0400

The proposal is that there is no separate CLIENT attribute; rather that 
the existing SERVER attribute keep its attribute number (0x8022), and 
just be renamed to SOFTWARE-TYPE or something like that. That attribute 
would then be used by both clients and servers.

-Jonathan R.

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 08 Jul 2008 14:00:24 -0700

Jonathan Rosenberg wrote:
> The proposal is that there is no separate CLIENT attribute; rather 
> that the existing SERVER attribute keep its attribute number (0x8022), 
> and just be renamed to SOFTWARE-TYPE or something like that. That 
> attribute would then be used by both clients and servers.
>
I agree that it sounds reasonable to just have one codepoint and its 
meaning depends on which end it came from. And since we're probably the 
only user of 0x8030 right now, we can switch to 0x8022 if that becomes 
the new consensus soon enough.

Matthew Kaufman

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2008 21:44:56 -0400

Well, unless no one objects before the deadline Monday, thats the plan.

-Jonathan R.

---

From: Philip Matthews <[email-masked]>
Date: Wed, 9 Jul 2008 08:59:05 -0400

On Tue, 8-Jul-08, at 17:00 , Matthew Kaufman wrote:
>> that the existing SERVER attribute keep its attribute number  
>> (0x8022), and just be renamed to SOFTWARE-TYPE or something like  
>> that. That attribute would then be used by both clients and servers.
>>
> meaning depends on which end it came from. And since we're probably  
> the only user of 0x8030 right now, we can switch to 0x8022 if that  
> becomes the new consensus soon enough.

This works for me. I'll provisionally update the text in TURN to  
correspond.

- Philip

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 09 Jul 2008 21:16:10 -0700

> This works for me. I'll provisionally update the text in TURN to 

Based on the direction this seems to be going, we've changed our code to 
use 0x8022. I guess that leaves 0x8030 unassigned and unused still.

Matthew Kaufman