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

Re: [Ecrit] LoST Review

Patrik, thanks for the read.  You found a lot of readability issues.

In-line you will find my responses to some of the issues:

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?"

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.

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?


I agree.  We need to clarify this.

(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.

How do the end device get the LOST URL? 

Via DHCP and other configuration methods.

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


Good catch.  The mapping in the schema says they are not:

div {
  mapping =
    element ns1:mapping {
      element ns1:displayName {
        xsd:string,
        attribute xml:lang { xsd:language }
      }*,
      service,
      (serviceBoundary | serviceBoundaryReference)?,
      element ns1:uri { xsd:anyURI }*,
      element ns1:serviceNumber {
        xsd:string { pattern = "[0-9*#]+" }
      }?,
      extensionPoint,
      expires,
      attribute lastUpdated { xsd:dateTime },
      source,
      attribute sourceId { xsd:token },
      attribute version { xsd:positiveInteger },
      message
    }
}


This draft contain a lot of words. Not as crisp as I would like to
see a protocol specification. Why for example does the above
paragraph point out "...provide a human-readable description..." etc,
and then the first thing that happen below in 5.1 is that it talks
about "Data source and version". Attributes that are not mentioned
above?


I agree.

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.

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?

Why is lang tag needed for the rendering? Because of alternate
displayName elements with different lang tags?


Yes.

   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.

-andy

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