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

Re: [Ecrit] comments on LoST


On Feb 13, 2007, at 11:18 AM, Jonathan Rosenberg wrote:
Firstly, the specification is somewhat confused about whether it is specifying a data object (like a presence document), in which case the semantics of the fields are critical, or whether it is specifying a protocol, in which case state machines, transactions, timers, failures, element behaviors, and so on, are relevant. I believe LoST is the latter not the former, yet the spec is mostly written as if it was the former and not the latter.

So the semantics of fields of a document passed by a protocol are critical, but the semantics of the fields in the protocol are not? This needs a better explanation in order to be actionable... or even convincing.

Secondly, I think the binding to http and https is not well specified, and many important details (minimum baseline mandatory requirements, timer considerations, usage of security techniques, pipelining, etc.) are not discussed at all.

Other than the timer considerations, I believe you have a point here. While other HTTP using dohickey's out there never actually do this, given the seriousness of non-interoperability with LoST probably means we need to cover this in more detail.

Thirdly, I have some concerns over the requirement for servers to support both geodesic-2d and civic for all queries. IN particular, I fear that it will be common for boundary objects to exist in only one form or the other, and I don't see how conversion can easily be done between the two.

I believe we say that all servers must RECOGNIZE both profiles. Not that they must have mapping data for both profiles, or be able to geocode or rev-geocode. No amount of specification can solve that problem. Either they have the data or they do not. In general, this should not be problem. Resolution paths will either follow a civic chain or a geo chain.

Also, the introduction is missing an important point that is obvious for us in this field but probably non-obvious for newbies. I'd suggesting adding the following text in the intro:

"Numerous techniques have been specified for the discovery of servers for a particular service, including NAPTR records, SVRLOC and similar protocols. However, there are an important class of services where the specific service instance that is to be connected to depends on the identity of the service and the location of the entity that needs to reach it. An example of this is emergency telecommunications services, where the service instance is a Public Safety Answering Point (PSAP) that has jurisdiction over the location of the user making the call. Here, the desired PSAP isn't necessarily the one that is topologically or even line-of-sight closest to the caller; rather, it is the one that serves the callers location based on geopolitical boundaries. For this reason, the selected service instance is a function of location and the desired service." 

I like it.

I wonder if there should be a separate port number for LoST. See RFC 3205.

If you mean well-known port numbers, then no. Specification of port numbers is done via U-NAPTR. In practice, I agree that they should not be 80 or 443 unless there is good reason.

Is there a way to use LoST without caching? To specify that this result is valid only for the purposes of satisfying this one query? Or to say that the results never expire?

Good question. I'm not sure about how to the former. The latter is practically done by setting the value to the year 4000. Perhaps we could modify the schema to allow the values of 'NO-CACHE' and 'NO- EXPIRATION' to be clearer.

The identifier is a random token with at least 128 bits of entropy
and can be assumed to be globally unique. It uniquely references a
particular boundary. If the boundary changes, a new identifier MUST
be chosen. Because of these properties, a client receiving a mapping
response can simply check if it already has a copy of the boundary
with that identifier. If so, it can skip checking with the server
whether the boundary has been updated. Since service boundaries are
likely to remain unchanged for extended periods of time, possibly
exceeding the normal lifetime of the service URL, this approach
avoids unnecessarily refreshing the boundary information just because
the the remainder of the mapping has become invalid.

Any guidelines about when a server is supposed to send a service boundary reference as opposed to the actual service boundary in a response?

Hmmm... good question. I would think that all authoritative servers would always send service boundary values so that caching resolvers may actually cache them. As for the resolvers, they probably know best what to do based on their configuration.

4. The declaration of whether geodetic-2d or civic is to be used as
the baseline profile. It is necessary to explicitly declare the
baseline profile as future profiles may be combinations of
geodetic and civic location information.

This doesn't make sense to me; I thought this spec defined both geodetic-2d and civic as baseline mandatory-to-implement.

It does, but defining new profiles requires the new profile to declare what baseline it is using... because that baseline needs to be used if the new profile is not recognized.

Requests and responses containing <location> or <serviceBoundary>
elements MUST contain location information in exactly one of the two
baseline profiles, in addition to zero or more additional profiles.
The ordering of location information indicates a preference on the
part of the sender.

THis seems odd. Why can't you include location in both of the location profiles if you have it? It might allow the server to figure out which is more accurate and use that one.

I believe there was a long thread about this, and the conclusion was "don't do it." Mostly because if you have both a civic and geo location, you can issue two separate queries.

 6.  If a server receives a request that only contains location
       information using profiles it does not understand, the server
       responds with a <locationProfileError> (Section 12.1).

based on your rules this should never happen. 

It shouldn't, that's right.  But we don't live in a perfect world.

A LoST server can respond indicating that the querier should redirect
the query to another server, using the <redirect> element. The
element includes a 'target' attribute indicating the LoST application
unique string (see Section 4) that the client SHOULD be contacting
next, as well as the 'source' attribute indicating the server that
generated the redirect response and a 'message' attribute explaining
the reason for the redirect response.

Is there support for multiple languages at once here, as is the case with warnings and errors?

It uses the same message pattern as warnings and errors, and neither support multiple.

You might want to include some discussion on timers. LoST layers a transaction protocol ontop of HTTP. How long should a client wait for a response? 

I'm not falling into that tarpit.  For a discussion on timers, see TCP.

Do LoST servers need to support pipelining? Do they have to provide both http and https support? Do clients need to support both? 

Pipelining: no.
Both HTTP & HTTPS: yes.
Should the doc specify this: yes.

What about authentication? Can digest be used? What about mutual TLS?

Support for any authentication in the client is optional. We should say this.

Generally, authentication and authorization is not required for
   mapping queries.  If it is, authentication mechanism of the
   underlying transport mechanism, such as HTTP basic and digest
   authentication, MAY be used.  (Basic authentication SHOULD only be
   used in combination with TLS.)

I this this last SHOULD has to be a MUST.

No. SHOULD is correct. Implementations will still be inter-operable if they violate this advice.

-andy

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