[Standards] Comments on XEP-xxxx: Shared XML Editing

Tom Pusateri pusateri at bangj.com
Thu Mar 11 04:35:41 UTC 2010

On Mar 9, 2010, at 11:16 PM, Peter Saint-Andre wrote:

> On 3/2/10 12:16 PM, Tom Pusateri wrote:
>> First, I want to comment on how much I like the approach of this
>> draft. It is simple and flexible and can be the basis for many
>> applications on top of it so I want to say nice job to the authors.
> Thanks for the feedback. We have not received many comments about this
> spec over the last few years. In general I think that SXE is probably
> good for small editing and whiteboarding sessions, but that it won't
> scale well to sessions with large numbers of participants (or even more
> than, say, ten participants).
>> Most of these comments are nits with the document and not the overall
>> design of the protocol but there are also a few blanks that need
>> filled in.
> This spec has a number of holes, some of which you have identified. In
> particular, the Jingle negotiation stuff was tacked on toward the end of
> our work on it, and was never properly vetted. If you're interested, we
> can make you a co-author / maintainer of the document so that you can
> fix it up.

I'd be glad to work on the document.

>> 1. In Example 3 where the Responder sends the session-accept, the
>> jingle stanza contains a 'host' attribute for
>> 'chamber at conference.shakespeare.lit'. This attribute isn't included
>> in Example 1 where the Initiator initially sends the
>> session-initiate. But both include a <host> transport element that
>> looks more like a user at host. The term host seems to be overloaded
>> here and its not clear what it refers to. It seems like the
>> conference jid should be in both the session-accept and the
>> session-initiate.
> If I recall correctly, the 'host' attribute was an experimental addition
> to the Jingle protocol that we were discussing at the time, which would
> have enabled you to delegate hosting of a session to a third party (such
> as a chatroom). I agree that we need to remove this from the <jingle/>
> element.
>> 2. Section 5 is titled, 'Determining the Host Type' yet there seems
>> to be little in this section that explains what host 'type' you're
>> trying to identify. It seems like its more Host or Entity
>> Capabilities. It seems like this section should encourage the use of
>> XEP-0115 to discover capabilities.
> Again, the idea was that I could invite you to a session that would be
> hosted by a third party. In this case you would query the host (using
> standard service discovery) to figure out if it was a MUC room, some
> kind of specialized reflector, etc.
>> 3. Section 6 describes how to advertise a session. I have some
>> questions here.
>> a. Is the session supposed to be a unique identifier? Is is supposed
>> to be a human readable name? If its not a name, can a 'name'
>> attribute and a 'description' attribute be added to help the user
>> determine if they want to connect to the session? If not, how would
>> this info be discovered without first connecting to the session and
>> synchronizing the document?
> More experimental stuff here. I think the ID is opaque to the user. If
> we want something more human-friendly then we'll need to add a name and
> description, as you say. We might want to design something like XEP-0137
> but for Jingle session descriptions. I posted about this last month but
> no one took me up on it:
> http://mail.jabber.org/pipermail/jingle/2010-February/001212.html

I will look into this.

>> b. Is there a preferred way to request the sessions in a serverless
>> messaging (XEP-0174) environment?
> Good question, because we don't have presence there, and we don't have
> PEP (XEP-0163) in a link-local environment either so we'd need to think
> that through. For now I think you'd send a specially-formatted message
> to the other party or parties. Another approach would be to advertise
> some of this information in the TXT records used in serverless mode.
>> 4. Section 8.1, point 1 says both the host and the invitor MUST offer
>> to send the state. Again the meaning of the term 'host' is not
>> clear.
> In a one-to-one setup, the host and the inviter are the same entity. In
> a situation where you have a MUC or a specialized editing server as the
> host, the joining entity would receive an offer from both.
>> 5. Section 8.2 says a joiner must abort the negotiation with other
>> users that offered to send state. It isn't clear what type of
>> response to a <state-offer/> is used to abort the negotiation?
> It seems that we need to define this. Perhaps a <refuse-state/> element
> would do.

Sounds good.

>> 6. Section 10.1, the formal definition of the <sxe/> element lists
>> the 'id' attribute as required but Example 9 in Section 6 doesn't
>> include an 'id' attribute.
> The 'id' appears to be required in the context of a session. Example 9
> is sent outside the context of a session.

Got it.

>> 7. Section 10.4, it is not clear what is meant by 'Server' here.
>> This whole section implies that you might have an editing server that
>> sends updates to all participants but it is not clear why a
>> participant choosing to serve other participants would have to have
>> any special definition. If a 'Server' really is a different type of
>> entitiy, then it needs to be explained.
> Yes, the server here would be a reflector of some kind (perhaps a MUC
> room or a specialized SXE reflector) -- not an XMPP router.
>> 8. Section 10.6.1, Table 7. 'replacefrom' and 'replacen' are not
>> defined anywhere. I quickly realized that 'replacefrom' meant from a
>> character position but it took a few reads to realize 'replacen'
>> meant to replace for 'n' characters. In the table entry for
>> 'replacefrom', it says only allowed if 'chdata' and 'replacefrom'
>> attributes are also included. This is confusing and would make more
>> sense if 'replacefrom' required 'replacen' and vice-versa.
> Yes, those are underspecified. Your suggestions are good, but in general
> the <set/> element needs to be defined more fully.

Thanks for the feedback. I grabbed the xml source and will fix these things.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4655 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100310/955ef2b9/attachment.bin>

More information about the Standards mailing list