[email protected]
[Top] [All Lists]

Re: [Ecrit] comments on LoST

Subject: Re: [Ecrit] comments on LoST
From: Henning Schulzrinne
Date: Wed, 14 Feb 2007 15:57:27 -0500

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
[email protected]

<Prev in Thread] Current Thread [Next in Thread>