[jdev] [JEP-33] Some questions

Norman Rasmussen norman at rasmussen.co.za
Tue Nov 29 02:26:08 CST 2005


On 11/29/05, Gaston Dombiak <gaston at jivesoftware.com> wrote:
> I was reading JEP-33 and some questions came up to my mind. :)
>
> 1) In the examples (section 9), messages being sent to BCC users are not
> including the <address type='bcc'/> element. Section 5 says: "Each 'bcc'
> recipient MUST receive only the <address type='bcc'/> associated with that
> addressee" so I think that we need to update the examples. Should the
> address element include the jid attribute when sending a message to the BCC
> user?
Examples in section 6.   That's meant to be read:  MUST not receive
bcc's for other people (as in standard email methodology).  It's not
meant to exclude sending of to and cc addresses

> 2) Section 3 specifies that IQ packets may also include an <addresses>
> element but not as a direct child. An example showing how an <addresses>
> element should be used would be very helpful. I guess that servers should
> check if an <addresses> element is being included inside the direct child.
> Is that correct?

Section 4 has good examples of what Section 3 means.  The whole point
of the addressing, is that servers don't need to have any extra
support for multicasting.

> 3) The <address> element may include a "node" attribute. How would the node
> attribute be used by the server and a client? An example may help me
> visualize a use case when a node is needed. Should the server just treat it
> as another attribute and send it to the client or remote server? Is it up to
> the client to use that information?
Are you considering that the 'server' is a standard jabber server,
with no extra multicast support.  There's an extra multicast component
that is handling all the multicast requests.

> 4) In section 2.2 (Discovering Server Support), does that mean that the
> disco#items may only be sent once? IOW, only the first disco items below the
> IM server level may provide the multicast service. Is this correct?
this exchange is pretty nasty, and could slow down messages if it's
done each time.  I think the JEP should explicitly state the process
of Service Discovery and should specifiy that components SHOULD cache
this detection.  I'd like to see this re-worked, but I'm not sure of a
better way to do it.

> 5) It would be nice if the JEP may include examples or more information
> about the address types: ofrom and oto, so it would be easier to understand
> when a client or server would use those address types.

JEP-0146 has yet to be updated to use JEP-0033, but I've chatted to
Remko about it, and he does plan to adopt the use of JEP-0033.   I
have also implemented JEP-0033 style forwarding in the Psi adhoc/rc
branch.

--
- Norman Rasmussen
 - Email: norman at rasmussen.co.za
 - Home page: http://norman.rasmussen.co.za/



More information about the JDev mailing list