On 11/29/05, Gaston Dombiak <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
