Subject: [xmpp] #12: namespace of <required/> element in stream features

From: "xmpp issue tracker" <[email-masked]>
Date: Mon, 14 Jun 2010 17:48:37 -0000

#12: namespace of <required/> element in stream features
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  major               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Regarding Section 4.2.2 (Stream Features Format), Waqas Hussain commented
 as follows:

 "Can we please have a namespace for the <required/> element?"

-- 
Ticket URL: <http://tools.ietf.org/wg/xmpp/trac/ticket/12>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Jun 2010 21:45:52 -0600

> #12: namespace of <required/> element in stream features

No, we can't. :)

We had a long discussion about this some months ago, and we concluded
that if a particular feature could be mandatory-to-negotiate then it
needed to define its own format for doing so. Thus we stepped away from
the idea of having a generic format for <required/> (and <optional/>) as
provisionally documented in an earlier version of 3920bis. At least that
is my recollection of the discussion. Feel free to disagree with my
recollection or to make a new argument for a generic format. Until then
I'm marking this as "wontfix".

Peter

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

---

From: "xmpp issue tracker" <[email-masked]>
Date: Thu, 24 Jun 2010 03:46:07 -0000

#12: namespace of <required/> element in stream features
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  major               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  wontfix           
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

  * status:  new => closed
  * resolution:  => wontfix

-- 
Ticket URL: <http://svn.tools.ietf.org/wg/xmpp/trac/ticket/12#comment:1>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Matthew Wild <[email-masked]>
Date: Thu, 24 Jun 2010 14:25:48 +0100

> I'm marking this as "wontfix".

+1 to this. Waqas and Matthew in disagreement shocker!

Matthew

---

From: Florian Zeitz <[email-masked]>
Date: Thu, 24 Jun 2010 15:49:43 +0200

> +1 to this. Waqas and Matthew in disagreement shocker!

So, maybe I'm just being stupid, but consider this:
An entity that receives features potentially won't recognize some of
those features. If it doesn't understand a feature it won't know whether
it's required. Therefore it could start trying to negotiate optional
features and end up being utterly confused as to why that failed. Is
that really what we want?
Also I think we have text about clients not trying to negotiate optional
features before they negotiated all required ones. That seems impossible
to me right now.

--
Florian Zeitz

---

From: Dave Cridland <[email-masked]>
Date: Thu, 24 Jun 2010 15:23:03 +0100

> that really what we want?

If an unknown feature is required, we're into diagnostic territory,  
rather than ways of making things work.

Besides, there's two things that can be required:

1) "Security". Meaning encryption, and therefore either TLS or SASL -  
and likely only TLS.

2) "Authentication". Meaning SASL. This is always mandatory.

I just don't see what other mandatory features we'll have.

I don't actually see the point in stamping TLS as mandatory except  
that there's no way to signal that XEP-0078 isn't supported.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Florian Zeitz <[email-masked]>
Date: Thu, 24 Jun 2010 16:56:42 +0200

> rather than ways of making things work.
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..."

> I don't actually see the point in stamping TLS as mandatory except that
> there's no way to signal that XEP-0078 isn't supported.
> 
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.

--
Florian Zeitz

---

From: Dave Cridland <[email-masked]>
Date: Thu, 24 Jun 2010 16:26:28 +0100

> 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".

> or with a different form of authentication or something yet  

It's too much effort to try and second-guess hypothetical situations.

Dave.

---

From: Florian Zeitz <[email-masked]>
Date: Thu, 24 Jun 2010 17:57:19 +0200

On 24.06.2010 17:26, Dave Cridland wrote:
> No, because compression wouldn't be offered at that point. It's not valid.
> 
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.

>From my point of view when defining Stream Negotiation we are defining a
general framework. 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".

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.

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 14:16:58 -0600

On 6/24/10 9:57 AM, Florian Zeitz wrote:
> 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

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

> that there never will be any additional MTN features of course and that

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/

---

From: Florian Zeitz <[email-masked]>
Date: Sun, 27 Jun 2010 23:59:41 +0200

>       deemed it rare enough that a generic format was not needed.

Sounds good to me.
Well, I do still like the "over-engineered" way better, but as long as
I'm in the minority this works for me.

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 16:34:42 -0600

> I'm in the minority this works for me.

You know, I liked the over-engineered way better too, but not strongly
enough to argue for it against the seeming consensus of implementers. :)

Peter

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