On 9/28/11 8:40 AM, Waqas Hussain wrote:
On Wed, Sep 28, 2011 at 1:44 AM, Peter Saint-Andre<stpe...@stpeter.im> wrote:
On 9/27/11 7:29 AM, Waqas Hussain wrote:
On Tue, Sep 27, 2011 at 2:36 AM, Peter Saint-Andre<stpe...@stpeter.im> wrote:
On 9/19/11 11:34 PM, Waqas Hussain wrote:
3. Service changing room nick
I'd like some text stating that a service can change the occupant's
nick at any time, including room join. An occupant MUST listen for
status code=100 in available presence for their current nick.
I understand nick changes on join, but not after that. What is the use case?
Implementing policies such as lowercasing all nicks (these happen on
room join, or when user initiates a nick change).
Right, the nick change use case makes sense. Sorry I missed that.
And there's also the
case of applying these when a user has not requested a nick change
(e.g., a user registers a nick with a room, the service may force a
nick on them when an admin accepts the registration).
Maybe. But why wouldn't the service enforce the nick rules on registration?
Example: User's current nick is 'psa', and sends a registration form
with nick 'stpeter', then on registration acceptance server switches
their nick to 'stpeter' for them.
I've added some text about that possibility.
Example 2: Room owner selects the "lowercase nicks only" option in the
room config. Room updates nicks of those present.
The spec does not define the "lowercase nicks only" option (or any
other, more advanced mapping option) so I don't see a good place to add
appropriate text.
What I want is text saying either this is allowed, or that this is not
allowed. My vote is for allowing the server to do this.
I think it's allowed, for sure.
Software which seems to follow my definition of a subject change, and
not your's: ejabberd, Tigase, Gajim, Miranda. And Prosody.
Pidgin is special, in that it displays the<body/> in the chat log,
and displays the<subject/> above the chatlog. M-Link on jabber.org
seems to return a<not-acceptable/> error on getting<subject/> with
any siblings. I didn't manage to find anything else which didn't
follow my definition.
Also, some servers add<delay/> elements to the subject message sent
to the client, with the time of when the subject was set, and could
add other things (crypto signatures, etc).
Yes, that's possible. But we've defined a subject change request as
message-with-subject-but-no-body for a long time now.
Naturally, if we were designing this all from scratch we'd probably use
an ad-hoc command for subject changes. :)
What I was implying was, most deployed software is not following the
'message-with-subject-but-no-body' rule, and is following the
'message-with-subject-is-a-subject' rule. Making the latter wrong and
the former right is going to make most deployed software
non-compliant.
I think we might need to have a longer discussion about this, or a call
for consensus.
11. Full-to-bare JID rewriting to support vCards
All(?) implementations are doing it, but it's not specified anywhere.
Should it be?
Yes, it should. Proposed text would be appreciated.
Err... a quick attempt, probably not too good:
[Section 16.4: IQ]
6. If an occupant sends an IQ get to another occupant with the child
element<vCard xmlns='vcard-temp'/>, the room SHOULD route the stanza
to the target occupant's bare real JID. The room should also rewrite
the 'from' attribute of the IQ result response to the initial target
occupant's full in-room JID. The room can store any state required in
'id' or 'from' attributes of the IQ get stanza it sends.
Not bad. But do we really want to special-case this for "vcard-temp"? At
the very least, why not "urn:ietf:params:xml:ns:vcard-4.0"? And at most,
the same logic might apply to extensions other than vCard...
I was mostly thinking of documenting historical practice. There's a
case for vcard4 as well, but perhaps that could be solved along with
the PEP in MUC problem. At that point we may even have the option of
deprecating the whole vcard-temp thing. I'm not too concerned about
documenting this, and we could leave the whole thing for later.
Aside: There has also some discussion in the jdev room and elsewhere
about the room itself querying and caching vCards (and other data) of
occupants, and serving occupants' vCard queries from that cache.
vCards account for most of the traffic on new room join.
I like that idea.
Peter
--
Peter Saint-Andre
https://stpeter.im/
