[Standards] s2s and gracelessly broken streams
stpeter at jabber.org
Fri Mar 30 17:09:30 UTC 2007
> Justin Karneges wrote:
>> On Tuesday 27 March 2007 9:44 pm, Mridul wrote:
>>> Justin Karneges wrote:
>>>> I'd also go as far as saying that we should decouple probing from being
>>>> explicitly related to the login process. For example, if a client were
>>>> to log off/on within a very short timeframe, I'd say that the server
>>>> shouldn't probe the whole roster again.
>>> Currently, not doing so would be breaking a bunch of (implied) MUST
>>> requirements from xmpp right now.
>>> Or you mean we can adapt this into bis spec ?
>> I think it is okay to violate a MUST if you know what you are doing.
> Where is psa when you need him :-)
He's somewhere around here. But he's having a hard time keeping up with
all the list traffic of late... ;-)
>> If there is anything in the text that says a server "MUST probe" when
>> a client logs in, I think it is safe to return cached answers and
>> probe some minutes later, without any harmful effect. Because
>> ultimately, it will look to the client as if you probed (and you are
>> probing, but just not at the exact moment -- the cached presence is
>> fresh enough).
The specs don't say anything about caching of presence information.
Naturally that could be added to an implementation note or best
practices document. And the spec could be written in a more careful fashion.
> I was actually wondering if there was a best practices doc, any
> normally/commonly practiced approaches, etc for tackling this problem.
> If yes, then we could rely on that and expect others to do so too
> (if/when it becomes widely implemented : but atleast there is something
> to look fwd to - and until then, file bugs/feature requests against,
> point customers to).
Sure. Never enough docs. :)
>> Changing a MUST to a SHOULD here might actually be worse, because that
>> might give license to not probe at all.
> Very true.
We can always define exceptions...
>> It comes down to good implementation judgment, but this is my own
Agreed. We hope that implementors will be smart. Not everything needs to
be specified in an RFC.
> I don't know if RFC-writers share it. :)
> I doubt if they will :-D
IMHO a best practices doc would be best. We don't like to bog down the
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards