ietf
[Top] [All Lists]

## Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00

2011-03-30 02:15:34
```Dave,

I explain the change with two figures in order not to be misunderstood (again).
I use SIP as an example; Jonathan gave a nice presentation.

Working Assumption previously:

............................          ..............................
.                          .          .                            .
.                +-------+ .          . +-------+                  .
.                |       | .  SIP     . |       |                  .
.                | Proxy |------------- | Proxy |                  .
.                |   1   | .          . |  2    |                  .
.                |       | .          . |       |                  .
.              / +-------+ .          . +-------+ \                .
.             /            .          .            \               .
.            /             .          .             \  SIP         .
.     SIP   /              .          .              \             .
.          /               .          .               \            .
.         /                .          .                \           .
.        /                 .          .                 \          .
.       /                  .          .                  \         .
.   +-------+              .          .                +-------+   .
.   |       |              .          .                |       |   .
.   |       |              .          .                |       |   .
.   | UA 1  |              .          .                | UA 2  |   .
.   |       |              .          .                |       |   .
.   +-------+              .          .                +-------+   .
.              Domain A    .          .   Domain B                 .
............................          ..............................

Figure 1: The SIP trapezoid

We have lots of standardization efforts that focus on the UA<->Proxy leg in the
RAI area.

Suggested new working assumption:

+-----------+             +-----------+
|   Web/    |             |   Web/    |
|   SIP     |     SIP     |   SIP     |
|           |-------------|           |
|  Server   |             |  Server   |
|     1     |             |     2     |
+-----------+             +-----------+
/                           \
/                             \   Proprietary over
/                               \  HTTP/Websockets
/                                 \
/  Proprietary over                 \
/   HTTP/Websockets                   \
/                                       \
+-----------+                           +-----------+
|JS/HTML/CSS|                           |JS/HTML/CSS|
+-----------+                           +-----------+
+-----------+                           +-----------+
|           |                           |           |
|           |                           |           |
|  Browser  | ------------------------- |  Browser  |
|           |          Media            |           |
|           |                           |           |
+-----------+                           +-----------+

Figure 2: Browser RTC Trapezoid

The server-to-server interaction I was referring to in my previous mail is the
interaction between server 1 to server 2. With cross-domain usage there still a
standardization need. This is what I mean by "the interoperability need
shifts".

Ciao
Hannes

```
```
On 3/29/2011 1:31 PM, Hannes Tschofenig wrote:
```
```Correct.

The interoperability need shifts away from the client-to-server side (for
example, to the server-to-server side;
```
```
No, that's wrong and I believe it is not what Eric said at all.

THERE IS STILL A CLIENT/SERVER PROTOCOL, HANNES.

ALL THAT CHANGES IS THAT THE CLIENT/SERVER PROTOCOL IS NOW PROPRIETARY.

I apologize for shouting.  I'm shouting for the classic reason that I'm
taking your continuing to misunderstand this multiply-repeated and very
basic point as a hearing problem.

Server-server is an entirely different task and different part of the
architecture.

d/
--

Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
```
```
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
```
```
```
```_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
```
 Current Thread For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00, Dave CROCKER Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00, Hannes Tschofenig Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00, Eric Burger Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00, Hannes Tschofenig Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00, Dave CROCKER Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00, Eric Burger Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00, Hannes Tschofenig <= Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00, Scott Brim Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00, Dave Cridland Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00, Eric Burger Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00, Hannes Tschofenig Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00, Dave CROCKER Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00, Scott Brim Message not available