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

Re: [Ecrit] LoST Review

On 31 jan 2007, at 16.53, Andrew Newton wrote:

On Jan 31, 2007, at 9:55 AM, Patrik Fältström wrote:
Oh, no! Not HTTP again!!! Why? Also, you can not rely on client certificates
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. 

A couple of counter comments:

1) We've been back and forth on HTTP. As anybody who has read this list knows, I've proposed other solutions. But we've settled here as a compromise. So I think it is fair that the group can ask "Why not HTTP?"

Of course. Regarding the "real world", I do understand why you choose HTTP. But, at the same time I will never stop asking "why http?" :-)

2) I agree that client side certs will not work, but it is not a technology issue. They certainly work technically. But the deployment model makes any type of client side authentication difficult.

Correct. I just would not like the architecture of the protocol rely on the fact certs in both ends work for anything else than encrypting the session. This was a generic advice I got as AD :-) from my wg participants once upon a time. Maybe the current AD have a different policy?

(2) Why do you not only use SRV records for this as lost is only
defined for HTTP/HTTPS?

lost:example.com -> _lost._tcp.example.com:80

I do not see any need for NAPTR records, unless LOST can be used with
some other protocol than HTTP. That is though not what it seems the
overall design is for.

I.e. possible over-engineering for an abstraction that in reality is
not, and will never, be used.

First, we do want the ability to specify full HTTP URIs in the resolution process. Second, we have talked about other protocols. The compromise to stick only with HTTP is that we don't have enough deployment experience, but we'd like the ability to do something later if necessary. 

Ok, fine.

How do the end device get the LOST URL?

Via DHCP and other configuration methods. 

Ok. Maybe that should be spelled out.

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

Else you will not be able to get a URI for the record itself, and I
think that would be an opportunity that should not be missed.

There is no need for this. Plus, a specific <mapping> may not apply. It depends on the input. 

Ok.

5.2.  Time of Last Update: The 'lastUpdated' Attribute

The 'lastUpdated' attribute describes when the mapping was last
changed. The contents of this attribute is a timezoned XML type
dateTime, in canonical representation. The attribute is REQUIRED. 

Note that according to 3.2.7.2 of http://www.w3.org/TR/2001/REC-
xmlschema-2-20010502/#dateTime (maybe I am looking at the wrong
source) the canonical representation of a time is always in UTC, so
the timezoned canonical version will always have 'Z' as the timezone
indicator.

This is what you want?

I think so, though we could be a bit more explicit, huh?

No no. I just wanted you to understand that the way *I* read your spec, the dateTime will always be in UTC. Just so people do not misunderstand what the paragraph in 5.2 say.

I think using UTC is fine.

   It contains a string of digits, * and # that a user on a
   device with a 12-key dial pad could use to reach that particular
   service.

Reference a syntax specification. Max 15 char in the string as in E.164?

I don't believe emergency numbers such as 911 or 112 or E.164 numbers.

Correct, as countries (Sweden at least) have as a requirement for E. 164 that it is possible to call an E.164 from any other E.164. They are from the same "namespace" though...and because of that have similar constraints. Maybe that is in the schema though?

   Patrik

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