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

Peter Saint-Andre stpeter at stpeter.im
Wed Mar 10 04:16:44 UTC 2010

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.

> 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/>

> 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:


> 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.

> 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.

> 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.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100309/72501619/attachment.bin>

More information about the Standards mailing list