[Standards] request for reviews: XEP-0045 v1.25rc5

Peter Saint-Andre stpeter at stpeter.im
Wed Sep 28 17:44:06 UTC 2011


On 9/28/11 8:40 AM, Waqas Hussain wrote:
> 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.

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/





More information about the Standards mailing list