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

Re: [Ecrit] LoST Review - part 1

On 31 jan 2007, at 16.54, Henning Schulzrinne wrote:

Comments on the comments; I'm hoping that Patrik is on the list.

Yes I am. But I have not read all messages as you could see on my comments :-)

or other mechanisms for the authentication of the client sending the query.
You need another layer of username/password/ whatever on top of TLS. TLS is
usable for the encryption of the traffic, but not (much) more.

Hmm, server certs seem to be fairly widespread. If they are deeply problematic, I think the world has larger problems than the use of LoST over HTTP.

Well, it all depends on what you use the fact the cert "worked" for. I just do not want you "trust" the cert more than what you in reality can.

As we all know, certs of CAs exist in browsers that we never check, and if one get a question about a cert from an unknown CA, we all "just click ok-continue". The end result because of this is an encrypted session, with some automatic checks between the DN in the cert and domain name.

That is not bad!

I just do not want you (as architects of this protocol) trust the fact you manage to get a TLS session "too much", for some definition of "too much".

I am a little bit nervous about the fact that the server can either
give back a referral OR do a recursive query. For the client the
difference is of course that all clients MUST implement the ability
to handle referrals, but on the other hand, the ability for a server
to query another server might not have to be in this document. Why is
that needed? Because it is needed to know wether the data comes from
an authoritative source? Or "just" because it imitates the way DNS
works?

A server can obviously choose to only refer, so I don't quite understand the comment. The reason for referrals is two-fold:

- allows intermediaries to cache results

- avoids multiple trips across a possibly narrow-bandwidth last-hop link

I think referrals are good. But, my recommendation is always regarding these things that a server can always refuse a request on doing referral (because of load or whatever), and because of that clients must be able to manage without getting the referral request fulfilled.

Are really all elements optional? sourceId, version, and source
attributes as well?

Just the elements, not the attributes. Maybe that's too non-obvious a distinction. 

For me it was. Sorry...

Should not the URI definition include the ability to also include the
sourceId and version in the URI?

At this point, the URI does not attempt to provide the ability to issue arbitrary LoST queries. We'd have to add a lot more to the URI to be able to do this, such as the location information and query type. One could define a URI that allow to simply retrieve a specific mapping, but not be rich enough to express a query.

What I was thinking of was the fact a reference to an object seems to contain both a lost URI for the server one go to, and the ID of the object itself. I "just" had the idea that the lost uri spec could be extended just a little bit with an optional object id, so it is possible to express the location of a location object (or whatever you call it) with a URI (only).

Why btw are several attributes in
Do you need time stamps on the via headers?

Good question; unlike email, it seems highly unlikely (and broken) if the requests take more than a few milliseconds for each hop, so second-resolution timestamps are unlikely to be useful and below that, clock synchronization seems to make the timestamp more or less random.

"No" is a perfectly alright answer. I just wanted to know that you had been thinking of "more data in a via header"... Time was an example.

   Patrik

_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit