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 archive did not produce the referenced
clarification. We /were/ told of two speakers -- who, indeed, are not on the
IAB -- is quite different. Could you please provide a pointer, so I can stop
worrying that my reading comprehension is getting worse than it's historically
terrible state...
plenary will be presented by persons who are not on the IAB, and whose
opinions will not necessary reflect the thinking of any IAB members.
What is odd about this statement is that it has been 2 IAB members (you and
Hannes) who were actively responding to the apps discussion thread. Your
postings were quite uniform in disagreeing with the concerns people were
expressing on the apps list, based on the title and description produced for an
IAB-sponsored plenary session.
As I read the text, there is no restraint in these bits of text. They declare a
new world and pretty much the end of apps protocol standards work.
Did you not really mean them? Certainly the comments being made now sound as if
the scope of the session is far more constrained.
While I do hear the recent notifications that pointedly detach the session from
the IAB, please note that choosing to consume this much time of this many IETF
folk lends it credibility and makes it a kind of endorsement.
Further, the repeatedly-cited draft that I reviewed was characterized as
providing more complete details behind the plenary, and that draft was written
by 3 IAB members and an AD who is an ex-IAB member.
I understand that this does not make it formal IAB work product, but the IAB is
hardly uninvolved at a deep level. There is a very clear and strong degree of
implicit IAB endorsement surrounding this work and this plenary.
From your more recent postings, it appears the actual content will have little
to do with what we were told by the title, the summary, or the cited draft.
On the other hand, what we are now being certainly sounds interesting...
On 3/28/2011 1:53 PM, Hannes Tschofenig wrote:
>> 2. Software
>>
>> The draft is predicated on a common point of confusion between software
architecture and network protocol architecture. They are typically independent.
>
> While we indeed try to keep software architecture and network protocol
> architecture separately
I found nothing in the draft that stated or maintained the distinction.
> my observation of the Web protocols we looked at is that this does not
seem to be the case here.
Please review my review comments concerning client/server interaction that has
any application-specific series.
> While theoretically one could have any form of mobile code in the current Web
> deployment we are not talking about a random language for mobile code but
Please explain that is relevant to the basic points I raise in the review.
> instead we are only talking about JavaScript here.
You are saying that, in this case, software architecture and networking
architecture are not separate. This suggests a very basic disparity in the
nature and roles of the two.
> So, this is not a confusion from our side but rather an observation of the
> widespread deployment and success of JavaScript.
There are two confusions that persist: One is the continuing assertion that
there is no higher level protocol involved in the interaction between the client
and the server -- which I covered in my review, and the other is that anyone is
disagreeing that JavaScript is popular (and even useful.)
>> An instructive demonstration that they are quite different is the history of
>> Netbios. (See RFC 1001/1002.) Simply put, an API can permit a variety of
>> very different protocols with very different properties, while an API never
>> specifies the exact details of bits over the wire.
>
> I fully agree that API in the way we use it in the IETF is not a protocol.
"In the way we use it"??? An API is never a protocol, Hannes.
> However, it seems that other folks outside the IETF do not follow that
> definition and people talk, for example, about the Geolocation API:
> http://dev.w3.org/geo/api/spec-source.html
>
> When you look at these "APIs" you will notice that they are actually more
> than just a programming interface. They are actually protocols.
Anyone can look Through the Looking Glass and define established terms in new
and conflicting way. Anyone also can simply misuse a term.
I would hope that the IAB could help the community in quality assurance on the
meaning and use of established terms, especially ones that were established long
before many IETF participants were born.
> So, there is a terminology mismatch here.
Surely not by any IAB members...
>> There is a reason that browsers have an option to disable JavaScript.
>>
>>
> As you note above there are security risks with that approach as well. We are
> aware of these challenges (and some other limitations).
I noted that you were. My comment was that your document seemed to treat this
issue as mild, whereas it is not only major, it is arguably beyond the state of
the art.
> We (the authors) believe that the IETF community should take a closer look at
> these security challenges (not only those that result from JavaScript but
> from the Web in general). To start the work on some of them the Websec
> working group was created last year in the IETF and the formation of a group
> in the W3C is pending.
Websec concerns detecting and prevent infection by viruses?
>> 5. Application Protocol
>>
>> The draft characterizes HTTP as "replacing" application protocols -- for
example:
>>
>>> The need for Internet standards beyond HTTP to
>>> implement an email inbox application consequently diminishes...
>>
>> So the draft asserts that POP and IMAP are no longer be needed. This view is
quite simply wrong.
>>
>> It misses the simple reality that an alternative environment based on HTTP
still has an application protocol running at the top of the stack; for
functional specificity between client and server, there must be additional
conventions followed between them.
>>
>> A set of conventions between network participants is called a protocol.
>>
>> HTTP and HTML5 and Javascript do not combine to specify email conventions.
If client and server are doing email interactions then there is an email protocol.
>>
>> A better "middleware" layer protocol platform might make it easier to
specify the higher-level email protocol. It might even allow more streamlined
email protocol details. But it does not eliminate the email protocol, since
that is where the semantics reside.
>>
>> Once the mobile agent is exchanged, the client/server interactions that
perform the application functions constitute the application protocol, whether
over HTTP or not and the protocol stack for this phase is the same as for any
other application protocol stack model:
>>
>> Mailbox Protocol or Mailbox Protocol
>> ---------------- ----------------
>> HTTP TCP
>> --------------- ...
>> TCP
>> ...
>>
>>
>
> I think the important aspect for IETF standards development is the following.
IMAP and POP are protocols standardized a while ago already. They exist and
that's fine.
> Imagine that you are a protocol designer that wants to develop a new feature
for an email client. As an example, you want to define a new extension that
makes certain email functions more efficient or so.
>
> You now have various options: You can write a new specification (like we did
in the past) or you could add a piece of HTML/JavaScript code to your deployment
and make use of it. It will immediately be available to your customers that use
email through a browser.
>
> Which approach is the right one to do? Well. It depends on a number of
factors.
This example goes to the core of the difference between network protocol and
software architecture. Your are describing a false dilemma.
The HTML/Javascript software choice is still going to be using a protocol back
to the server and there is nothing with your using a standard like IMAP and
choosing to do a proprietary upgrade to it.
After demonstrating its utility, you might even choose to pursue standardizing
it.
>> The draft further confuses the use of proprietary protocols with the absence
of protocols.
...
>
> It is unfortunate if the draft gave the impression that these JavaScript
mechanisms aren't protocols. Clearly they are, as you point out.
> We need to make this more clear.
Dandy.
>> The draft also appears to erroneously believe that standardization requires
starting with a standards effort at the beginning of a technical effort.
Starting the standards process later into the lifecycle of a protocol often
works quite well, as demonstrated by NFS, SSL/TLS, Jabber/XMPP, and DKIM.
>
> I am not sure we say that. We definitely do not believe that.
Dandy.
>> The draft appears to see only the benefits in this reliance on proprietary
protocols, without any sense of the attendant detriments.
...
>
> We may need to describe the pros and cons more in the document.
Yes.
>> Application protocol and object standardization activities are required, if
data are to be shared.
>>
> The need for server-to-server communication does not seem to go away, as we
state in the draft. Also the work on data formats seems to be needed but it
turns out to be quite difficult, as we notice for a long time on location,
contact information, etc.
It does not matter whether it is server-server or client-server, with respect to
this point: If application services are to share things, the sharing needs to
be standardized.
Sharing happens within a user's host, not just between servers.
>> 7. Client Thickness
..
>> The draft fails to demonstrate or deal with these distinctions.
>
> We actually do not deal with purely "screen sharing" approaches. That's also
> an interesting area of work that people are looking into (even for games).
The draft gave no indication of which model it wants to pursue.
>> 8. Extraneous
>>
>> The draft has an extended discussion about a number of important hardware
and software limitations that appear to be independent of the language and
platform, as well as having nothing to do with any protocol. These should be
removed, or else they should be used as a basis for recommending specific work,
in the IETF or elsewhere.
>>
>>
> The hardware and software limitations are important for judging where
limitations when going for a Web based environment with protocol design.
As discussed in the draft, some or all of the limitations were universal, not
just about web apps.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf