On 6/24/10 9:57 AM, Florian Zeitz wrote:
> On 24.06.2010 17:26, Dave Cridland wrote:
>> On Thu Jun 24 15:56:42 2010, Florian Zeitz wrote:
>>> My point is we don't have to be. Either I connect to a server and my
>>> client tells me right away "I can not connect to this server because a
>>> required feature is not supported: <feature xmlns='urn:foo'/>" or it
>>> tells me later on "There was an error trying to negotiate stream
>>> compression, not sure why though..."
>>>
>>>
>> No, because compression wouldn't be offered at that point. It's not valid.
>>
>> The error would be "No authentication mechanisms offered".
>>
> That's just not true. A MTN feature could be offered next to compression
> after SASL negotiation. As is actually the case now for resource binding
> right now.
> 
>>> I personally can't think of anything else either, but just because we
>>> can't imagine it doesn't mean it won't happen.
>>> Maybe someone will come up with a reason to require Stream Compression
>>> or with a different form of authentication or something yet different.
>>
>> It's too much effort to try and second-guess hypothetical situations.
>>
> From my point of view when defining Stream Negotiation we are defining a
> general framework. 

We started to go down that path last year and there was pretty strong
list consensus (IMHO) that we were over-engineering stream negotiation
and that we really didn't need a completely generic framework.
Theoretically I agree that it would be cleaner to have a completely
generic framework, but practically speaking I don't think we'll need one
(because we have a fairly coherent developer community and if we do end
up someday defining another mandatory-to-negotiate feature we'll discuss
it for quite a while before it becomes a reality).

> And as we have some features that are MTN IMHO we
> need a way to declare them as such. This is no hypothetical future use-case.
> We have a point during negotiation where the client has to ask himself
> "Are there more MTN features?" and I think it's quite unsatisfactory if
> the answer can be "Maybe".

It's theoretically unsatisfactory but the group seems to be saying that
it's something we can live with.

> If we go another route I think we would definitely need to be more
> honest. There is no point where all features are voluntary to negotiate,
> there is only a point at which the clients considers all features to be
> voluntary to negotiate. And there are no guarantees that you are
> actually cleared for sending stanzas at that point. Unless you assume
> that there never will be any additional MTN features of course and that
> seems naive to me.

Yes, it's good to be honest about the tradeoffs here. I've added the
Informational Note shown below, on the assumption that the text there is
indeed the consensus of this group (we can discuss whether that is
indeed the case).

###

   If a particular stream feature is or can be mandatory-to-negotiate,
   the definition of that feature needs to do one of the following:

   1.  Declare that the feature is always mandatory-to-negotiate (e.g.,
       this is true of resource binding for XMPP clients); or

   2.  Specify a way for the receiving entity to flag the feature as
       mandatory-to-negotiate for this interaction (e.g., this is done
       for TLS by including an empty <required/> element in the
       advertisement for that stream feature); it is RECOMMENDED that
       stream feature definitions for mandatory-to-negotiate features do
       so by including an empty <required/> element as is done for TLS.

      Informational Note: Because there is no generic format for
      indicating that a feature is mandatory-to-negotiate, it is
      possible that a feature which is unknown to the initiating entity
      might be considered mandatory-to-negotiate by the receiving
      entity, resulting in failure of the stream negotiation process.
      Although such an outcome would be undesirable, the working group
      deemed it rare enough that a generic format was not needed.

###

Peter

-- 
Peter Saint-Andre
https://stpeter.im/