[Standards-JIG] Re: UPDATED: JEP-0060 (Publish-Subscribe)

Peter Saint-Andre stpeter at jabber.org
Tue Jul 13 22:28:32 UTC 2004

On Fri, 09 Jul 2004 13:44:37 +0200, Ralph Meijer wrote:

>  - The text suggests that implementing subscribing to a node is optional
>    (SHOULD). I think this is good, however, it should be a disco feature.
>    For example: pubsub#subscribe. This might also cover the support for
>    unsubscribing.

Agreed. And yes, this feature + configuration option covers both subscribe
and unsubscribe. I've added this feature to the JEP.

>  - I see that requesting current affiliations is a MUST. The requirements
>    (section 3), don't state this a mandatory feature. I'd say barebones
>    implementations don't need this, and this should become a SHOULD.
>    Naturally it would become a feature (pubsub#request-affilations).

I don't have strong feelings about this one, so I'll defer to the JEP

>  - The requesting of the meta-data is a MUST whereas the node discovery
>  via
>    disco is a MAY. This is odd. From a security stand, you might want to
>    refrain from letting others know of the existence of nodes. Being
>    obliged to implement requesting meta-data from nodes enables probing
>    for nodes. Also, this is the only MUST that requires support for
>    handling x:data (in this case generating it), and is overkill for
>    barebones implementations.

I think perhaps this was mis-phrased in the text -- I thought it was odd,
too. I think pgm meant to say that service discovery must be supported and
that an implementation may or should support service discovery extensions
(metadata) as well. It seems that metadata is being used in two senses
here: one is standard service discovery information (features supported,
etc.), the other is extended information encoded using the x:data protocol
in accordance with JEP-0128. Also the phrasing of the requirement is a bit
ambiguous (!) in one other respect: it says that an entity must be allowed
to query for metadata, but it doesn't say that a node must return metadata
or support that feature. So it's a bit weak, IMHO. But perhaps the JEP
author could clarify his intent. :-)
>    I think this, also, should be a SHOULD, with the feature
>    pubsub#meta-data and should be removed from the requirements in
>    section 3.

+1 to the service discovery feature -- I've added that.
>  - The Requirements (section 3), has a list of the basic features a
>  pubsub
>    service MUST implement. The must is not capitalized, and further, the
>    last two bullets are SHOULDs, and should not be in this list.

Conformance terminology is fun. I've fixed these.


More information about the Standards mailing list