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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]