[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] comments on LoST
inline.
Andrew Newton wrote:
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.
No - I'm not saying that of course. What I was expecting is something
like a section that said "client behavior" and one called "server
behavior". The client behavior one would tell you rules for constructing
each of the requests, what to do with various responses, how to handle
caching, error handling, and so on. Server behavior would be similar,
talking about rules for recursion, caching, and so on.
Perhaps its a matter of taste.
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.
OK.
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.
Right.
Not
that they must have mapping data for both profiles, or be able to
geocode or rev-geocode.
You are more or less requiring one of those two options. Particularly
for boundary information, I think you are saying that a server *will*
have to either be able to:
1. have boundary data stored in both formats, OR
2. be able to convert from geodesic polygons to civic wildcard formats
automatically AND convert from civid wildcard fromats to geodesic
polygons automatically
Seems to me that #2 is more or less impossible, and that doing it would
pretty much require #1 anyway. If that is the case, I want to make sure
it is clearly stated.
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.
Right. SO what if a server has boundary information in civic format and
a client makes a query in geodesic format.
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.
Even if you use NAPTR/SRV you can still have default port numbers; SIP
does this (port 5060 default). People seem to still find comfort in
default port numbers for firewall configuration. Trust me, I'm well
aware of its practical limits....
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.
It may be a non-requirement; I just want to make sure it was considered.
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.
So, then why bother even supporting explicit inclusion of a service
boundary? Less options in a protocol is better.
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.
I'm still lost here (no pun intended). You already specify rules that
say that a server has to support both baselines. So, if you add a new
profile, why does it matter whether the client includes geodesic vs.
civic profiles in addition when it sends a query?
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.
OK. Might want to say that.
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.
Right. So you should mention this shouldn't happen.
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.
Perhaps I was thnking of display names...
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.
It may be a tarpit, but I dont think you can just skirt the issue
entirely. Its not really a tcp issue at all. If a server needs to go to
other servers to get an answer, and THOSe servers are delayed or down,
what happens? Should the client retry right away? How does the client
know that the server is trying (in which case a retry on a different
server is useless) vs. unresponsive (in which case a retry is useful)?
This is one of the dangers of running on http as a substrate. LoST is
NOT like HTTP in its use of multi-hop resolution. That brings up all
kinds of new failure modes that you need to consider.
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.
Oh? Why not? Could come in handy when the client is not an endpoint but
something like a sip proxy or call agent.
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.
Right.
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.
Well, this is another tarpit as you know. I think anything less than a
MUST will run you into some interesting discussions with IESG.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Cisco Fellow Parsippany, NJ 07054-2711
Cisco Systems
jdrosen at cisco.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit