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 >> '[email protected]'. 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 u...@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. Tom
smime.p7s
Description: S/MIME cryptographic signature
