Subject: [Ecrit] draft-ietf-ecrit-lost-sync-15.txt

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jan 2012 21:20:37 +0200

Hey Julian, 

as discussed in our call today I have updated the document. I submitted version -15 and put the ECRIT WG on CC to let everyone know about the proposed changes. 

As a background for others on the list, Julian reviewed the document a while ago and I made changes but Robert noticed that I had missed a few issues. Here is his review: 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01798.html

There are two interesting issues: 

1) HTTP POST is used by LoST Sync

When Henning and I worked on the LoST Sync specification we just followed the design of many of our other HTTP protocol designs (like LoST, HELD, etc.). 

Julian had some concerns that the tunneling of XML over HTTP could lead to undesired behavior when the protocol is run over proxies (rather than in an isolated environment) if we do not precisely specify what these devices do with the LoST Sync protocol. There are various ways to deal with that problem and, for example, using a different port number (as suggested in BCP 56) is one option. Another option is to always use TLS. 

I have now changed the draft in such a way that it mandates the usage of TLS. I believe that this is quite appropriate for a protocol that is so security sensitive. 

I believe that this addresses the concerns.

2) LoST Sync Relax NG Schema Registration

RFC 3688 defines the "The IETF XML Registry" and the abstract says:

   This document describes an IANA maintained registry for IETF
   standards which use Extensible Markup Language (XML) related items
   such as Namespaces, Document Type Declarations (DTDs), Schemas, and
   Resource Description Framework (RDF) Schemas.

Note that the document does not talk about Relax NG schemas. We have, for example, with LoST and other specifications uses this XML registry to register our Relax NG schemas. That's not quite what the registry was designed for. 

Julian has a token now to investigate this issue. 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jan 2012 21:11:32 +0200

Hi Julian, 

On Jan 15, 2012, at 6:09 PM, Julian Reschke wrote:

> Yep.
> The protocols mentioned above essentially use HTTP as a tunnel. I would NOT recommend them as an example of protocol design unless you are sure that you can control senders, receivers, and intermediates. Also keep in mind that one of the advantages of using HTTP is that you can reuse existing components (like libraries and server frameworks), in which case using HTTP the wrong way can lead to later pain.

But didn't we add directives that control the behavior of the HTTP protocol to, for example, control caching? 
Isn't this enough or the wrong approach? 

Ciao
Hannes