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....
Agreed, but what would they be? 80 and 443? Since it isn't
essential to specify, I don't see a need to do so.
You'd go do an iana allocation request and include them in the spec.
I see no reason for LoST to use anything beyond port 80 or 443 as
long as it uses HTTP/S. LoST is very much in the same spirit as XML-
RPC or SOAP, both of which use port 80/443.
Err, I'm confused. I was suggesting that it might be easier to ONLY
have a service boundary reference in the findServiceResponse. That
is, to drop support for including the actual service boundary in a
find service response. Rather, the client always has to fetch it
separately. I was asking what the use case was for EVER including
the actual service boundary (as opposed to the reference) in a
findServiceResponse. If there is none, we can drop it.
I've made that argument in the past. The one argument that was
offered in favor of retaining by-value inclusion of boundaries is
that civic boundaries are likely to be small in size, so the overhead
of retrieving the boundary separately is far larger than including
it, due to the need to issue a separate query for the by-reference case.
Personally, I still think that simplicity would be a good thing here.
The real issue here is, will we see interop problems because
servers timeout before clients do? Seems like there are real things
here needing specification.
The case that can occur is that the seeker asks the resolver and the
resolver asks the authoritative server (or similar variations).
If the seeker timeout is shorter than the resolver timeout, nothing
bad happens - the resolver caches the answer it eventually got for
the next querier, possibly a re-attempt by the same seeker.
If the converse occurs (seeker timeout > resolver timeout), the
seeker gets a failure indication from the resolver.
Thus, I don't see a need to specify an explicit timeout. In many
practical cases, the timeouts will be driven by the TCP or HTTP
library, so they may not be configurable in any event. Any such
choice would likely be completely arbitrary.
Ecrit mailing list