[Standards] request for reviews: XEP-0045 v1.25rc5
waqas20 at gmail.com
Wed Sep 28 14:40:57 UTC 2011
On Wed, Sep 28, 2011 at 1:44 AM, Peter Saint-Andre <stpeter at 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 <stpeter at 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.
Example 2: Room owner selects the "lowercase nicks only" option in the
room config. Room updates nicks of those present.
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.
>> 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
>>>> 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.
More information about the Standards