Subject: RE: [Simple] BIND and relays documentation

From: [email-masked]
Date: Tue, 25 Nov 2003 09:52:59 +0200

Hi Miguel,

I don't agree with you. The relay case will be seen as an extension of MS(R)P and therefore all methods to support relays should be defined in that document.

If endpoint implementers want to support relays for NAT traversal, then they better implement whatever is documented in the relay document.

Regards,
Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Miguel A. Garcia
> Sent: 24.November.2003 20:48
> To: Ben Campbell
> Cc: Simple WG
> Subject: [Simple] BIND and relays documentation
> 
> 
> Hi:
> 
> A question about the recent decision to split the MSRP 
> protocol into a 
> relay-less document and a document that details the use of relays.
> 
> I would like to understand if the idea is to document the 
> BIND primitive 
> in the relay-less document or in the relayful document.
> 
> Some folks may argue that the BIND primitive is only used in the case 
> there are relays in the path, and as such, it should be documented in 
> the relays document. However, in doing so, we may risk that 
> end points 
> will not implement the BIND primitive ever, and therefore will not 
> support the operation through relays.
> 
> I am in favour of documenting the BIND primitive in the core MSRP 
> document, in spite that the relay operation will be described in the 
> relays document.
> 
> Is this something that the working group is thinking?
> 
> /Miguel
> -- 
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                          Jorvas, Finland
> mailto:[email-masked]     Phone:  +358 9 299 3553
> mailto:[email-masked]        Mobile: +358 40 514 0002
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 25 Nov 2003 11:42:36 +0200

This proposal is an incomplete specification. Precluding support for 
proxies and NAT these days seems a bad idea. If you allow to have a 
collection of endpoints deployed that do not support relays, we will 
definitely get problems.

/Miguel

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Nov 2003 09:34:38 -0600

> collection of endpoints deployed that do not support relays, we will 

I think there are two sides of this. If we treat relays as an extension, 
then it is important that endpoints who do not know about relays can 
still talk to endpoints that know about and want to use relays. But it 
is not so important that all endpoints know how to initiate the use of 
relays.

In the 01 draft, the use of a relay is transparent to the visitor, 
unless the visitor wants to use a relay of its own. I think it is 
reasonable to expect the relay draft to maintain that transparency. This 
makes it possible for an endpoint that does not know about relays to 
participate in a relay-hosted session. BIND does not affect this in any way.

>> I don't agree with you. The relay case will be seen as an extension of 
>> MS(R)P and therefore all methods to support relays should be defined 
>> in that document.
>>
>> If endpoint implementers want to support relays for NAT traversal, 
>> then they better implement whatever is documented in the relay document.
>>
>> Regards,
>> Hisham
>>
>>
>>> A question about the recent decision to split the MSRP protocol into 
>>> a relay-less document and a document that details the use of relays.
>>>
>>> I would like to understand if the idea is to document the BIND 
>>> primitive in the relay-less document or in the relayful document.
>>>
>>> the relays document. However, in doing so, we may risk that end 
>>> points will not implement the BIND primitive ever, and therefore will 
>>> not support the operation through relays.
>>>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Nov 2003 09:34:38 -0600