Subject: [www.ietf.org/rt #37575] transcript of IETF-80 tech plenary discussion?
From: Wanda Lo via RT age...@ietf.org
Date: Mon, 09 May 2011 10:28:23 -0700
To: jeff.hod...@kingsmountain.com
Hi Jeff,
http://www.ietf.org/proceedings/80/minutes/plenaryt.txt
The minutes are based on Renee's
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:
..
. .
Right. You might add control boundaries. What's happening is that
the server is extending a pseudopod down into the user environment, so
that the 'user agent' is within its control boundary. There will
still be other apps, other user agents, in the user environment that
are outside of service
And the Proxy - Browser interaction is 100% out of IETF scope. For that
matter, the IETF should be pointing out how dangerous and evil such a proposal
is, as it means the end of consumer choice and a competitive marketplace for
clients.
On Mar 30, 2011, at 9:14 AM, Hannes Tschofenig wrote:
On Wed Mar 30 08:20:22 2011, Scott Brim wrote:
Right. You might add control boundaries. What's happening is that
the server is extending a pseudopod down into the user environment,
so
that the 'user agent' is within its control boundary. There will
still be other apps, other user agents,
As said, the implications of such a decision have been discussed and there are
pros and cons to the approach.
evil is probably not a correct clarification.
On Mar 30, 2011, at 10:18 AM, Eric Burger wrote:
And the Proxy - Browser interaction is 100% out of IETF scope. For that
matter, the
I think this encapsulates what Dave is trying to get across:
Yes, it is MUCH easier for a server developer to stuff in a little more
JavaScript.
Now, you have a 100% proprietary system, with no hope or desire for
interoperability, that gets deployed much faster than someone taking their
Correct.
The interoperability need shifts away from the client-to-server side (for
example, to the server-to-server side; see Jonathan's plenary presentation
slides) and to building blocks that are considered useful in various contexts.
The BarBOF about JSON signing and encryption we had
On 3/29/2011 1:24 PM, Eric Burger wrote:
I think this encapsulates what Dave is trying to get across:
Yes, it is MUCH easier for a server developer to stuff in a little more
JavaScript.
Now, you have a 100% proprietary system, with no hope or desire for
interoperability, that gets deployed
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
On Tue, Mar 29, 2011 at 13:24, Eric Burger
ebur...@standardstrack.com wrote:
Yes, it is MUCH easier for a server developer to stuff in a little
more JavaScript.
Now, you have a 100% proprietary system, with no hope or desire for
interoperability
There has to be interoperability in the
Got it in 1.
On Mar 29, 2011, at 1:40 PM, Dave CROCKER wrote:
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
Hi Dave,
thank you for the detailed review of the draft.
For time reasons I only focus on a few minor items; a more detailed response
will follow later.
2. Software
The draft is predicated on a common point of confusion between software
architecture and network protocol architecture.
Beginning of the Technical Plenary... this is my version of posting to
bad-attitude...
On 3/27/2011 4:59 PM, Peterson, Jon wrote:
Without speaking to your review of the draft as such, let me restate what has
already been said on the apps-discuss list:
Jon,
Forgive me, but a review of that
14 matches
Mail list logo
