headers
Peter Saint-Andre | 3 May 2004 23:02

Re: XMPP WG Documents core-23 + im-22

My apologies for the slow reply -- I was out of town.

Overall it seems fine to remove the text Allison mentions. However, for 
the sake of future conformance testing of XMPP implementations, I think 
it's important to note that XMPP-Core may be more or less restrictive 
regarding certain stanza handling rules than XMPP-IM or some other 
application layer specification. Presumably the application layer 
specification would rule in such cases if it explicitly said so, but I 
suppose we can leave that up to the relevant specification. Example: as 
it stands today, XMPP-IM overrides several of the server handling rules 
in XMPP-Core; this makes conformance testing potentially problematic: 
does an implementation that conforms to the stanza handling rules in 
XMPP-IM therefore not conform to XMPP-Core? It seemed best to make the
relationship between the XMPP-Core specification and any application 
layer specifications explicit on this point (I received feedback about 
it off-list), but it may not be as important as I once thought.

Peter

On Thu, Apr 29, 2004 at 12:38:55PM -0400, Scott Hollenbeck wrote:
> The IESG just completed re-review of two XMPP WG documents:
> 
> draft-ietf-xmpp-core-23.txt
> 
> draft-ietf-xmpp-im-22.txt
> 
> These documents were reviewed again because of changes that were introduced
> after the documents were initially approved by the IESG.  im-22 was
> re-approved for publication as an RFC.  There is one issue remaining with
> core-22 (per Allison Mankin), described in the IETF I-D tracker.  I'll
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 3 May 2004 23:26
Picon
Favicon

Protocol Action: 'Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence' to Proposed Standard

The IESG has approved the following document:

- 'Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and 
   Presence '
   <draft-ietf-xmpp-im-22.txt> as a Proposed Standard

This document is the product of the Extensible Messaging and Presence Protocol 
Working Group. 

The IESG contact persons are Scott Hollenbeck and Ted Hardie.

Technical summary:

This document defines an instant messaging and presence protocol based on 
XMPP defined in draft-ietf-xmpp-core. It defines which XMPP stanzas are used

to communicate instant messages, the data of which is in UTF-8 for 
internationalization purposes. It also defines which XMPP stanzas are used 
to communicate presence information. There is extensive text in this 
document concerning the management of presence subscriptions, contact lists 
(called "rosters"), and privacy lists to meet the requirements of RFC 2779.

This document defines XML schemas for instant messaging and presence used 
in conjunction with XMPP. It also gives numerous examples. The document 
does not address end-to-end security of data nor does it discuss compliance 
with the CPIM documents. There are two companion documents to this 
one which describes these topics.

Working Group summary:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Saint-Andre | 3 May 2004 23:44

Re: FW: DISCUSS: draft-ietf-xmpp-cpim

Are there any WG objections to the following text?

******

4.2.7 Require Header

   "Message/CPIM" objects MAY include an optional 'Require' header to
   specify mandatory-to-recognize features.  In general, such a header
   would be included by the non-XMPP sending application to (1) insist
   that the receiving application needs to understand functionality
   specified by a particular header or (2) indicate that some non-header
   semantics need to be implemented by the receiving application in
   order to understand the contents of the message (e.g.,
   "Locale.MustRenderKanji").  Because the mandatory-to-recognize
   feature would be required of the XMPP receiving application rather
   than the XMPP-CPIM gateway itself, the gateway cannot properly handle
   the 'Require' header without detailed knowledge about the
   capabilities of the XMPP receiving application.  Therefore, it seems
   appropriate that the XMPP-CPIM gateway SHOULD return a warning or
   error to the non-XMPP sending application if it includes one or more
   'Require' headers in a "Message/CPIM" object; the exact nature of the
   warning or error will depend on the nature of the non-XMPP technology
   used by the foreign system, and is not defined herein.  Furthermore,
   any mapping of the 'Require' header into XMPP or an XMPP extension is
   left up to the implementation or to a future specification.

******

On Wed, Apr 28, 2004 at 05:40:27PM -0500, Peter Saint-Andre wrote:
> Yes, that seems most reasonable to me for now -- especially since even
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Hildebrand | 4 May 2004 02:21

RE: FW: DISCUSS: draft-ietf-xmpp-cpim

Close, but I think it might be nice to allow the gateway to keep going, if
it can determine, throught whatever means (disco, client capabilities, etc.)
that the endpoint supports a feature that the gateway can map the 'must
understand' into.

Change SHOULD to MAY, and I think you're fine.

-- 
Joe Hildebrand

> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter <at> jabber.org] 
> Sent: Monday, May 03, 2004 3:45 PM
> To: Joe Hildebrand
> Cc: xmppwg <at> jabber.org
> Subject: Re: [xmppwg] FW: DISCUSS: draft-ietf-xmpp-cpim
> 
> Are there any WG objections to the following text?
> 
> ******
> 
> 4.2.7 Require Header
> 
>    "Message/CPIM" objects MAY include an optional 'Require' header to
>    specify mandatory-to-recognize features.  In general, such a header
>    would be included by the non-XMPP sending application to (1) insist
>    that the receiving application needs to understand functionality
>    specified by a particular header or (2) indicate that some 
> non-header
>    semantics need to be implemented by the receiving application in
(Continue reading)

Permalink | Reply | 4 comments |
headers
Pete Resnick | 4 May 2004 04:07

RE: FW: DISCUSS: draft-ietf-xmpp-cpim

On 5/3/04 at 6:21 PM -0600, Joe Hildebrand wrote:

>>the XMPP-CPIM gateway SHOULD return a warning or error to the 
>>non-XMPP sending application if it includes one or more 'Require' 
>>headers in a "Message/CPIM" object
>
>Close, but I think it might be nice to allow the gateway to keep 
>going, if it can determine, throught whatever means (disco, client 
>capabilities, etc.) that the endpoint supports a feature that the 
>gateway can map the 'must understand' into.

Right, but....

>Change SHOULD to MAY, and I think you're fine.

No. SHOULD means "that there may exist valid reasons in particular 
circumstances to ignore a particular item, but the full implications 
must be understood and carefully weighed before choosing a different 
course." [RFC-2119] That's exactly what's being said here, and it's 
what's intended. MAY means that the gateway can choose to send the 
warning or error, or not, on a whim depending on what it feels like. 
That's *not* what we want to say.

SHOULD is correct here.

pr
--

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
(Continue reading)

Permalink | Reply | 3 comments |
headers
Joe Hildebrand | 4 May 2004 04:36
Gravatar

Re: FW: DISCUSS: draft-ietf-xmpp-cpim

How about just another clause, then, that says something like:

unless the gateway can determine that the receiving entity can support 
an equivalent XMPP mechanism that it can translate into, the gateway 
SHOULD...

-- 
Joe Hildebrand
Denver, CO, USA

On May 3, 2004, at 8:07 PM, Pete Resnick wrote:

> On 5/3/04 at 6:21 PM -0600, Joe Hildebrand wrote:
>
>>> the XMPP-CPIM gateway SHOULD return a warning or error to the 
>>> non-XMPP sending application if it includes one or more 'Require' 
>>> headers in a "Message/CPIM" object
>>
>> Close, but I think it might be nice to allow the gateway to keep 
>> going, if it can determine, throught whatever means (disco, client 
>> capabilities, etc.) that the endpoint supports a feature that the 
>> gateway can map the 'must understand' into.
>
> Right, but....
>
>> Change SHOULD to MAY, and I think you're fine.
>
> No. SHOULD means "that there may exist valid reasons in particular 
> circumstances to ignore a particular item, but the full implications 
> must be understood and carefully weighed before choosing a different
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pete Resnick | 4 May 2004 04:43

Re: FW: DISCUSS: draft-ietf-xmpp-cpim

On 5/3/04 at 8:36 PM -0600, Joe Hildebrand wrote:

>How about just another clause, then, that says something like:
>
>unless the gateway can determine that the receiving entity can 
>support an equivalent XMPP mechanism that it can translate into, the 
>gateway SHOULD...

Isn't that what the previous sentence says?

"Because the mandatory-to-recognize feature would be required of the 
XMPP receiving application rather than the XMPP-CPIM gateway itself, 
the gateway cannot properly handle the 'Require' header without 
detailed knowledge about the capabilities of the XMPP receiving 
application."

Do we really think it needs to say, "unless you have the detailed 
knowledge about the capabilities of the XMPP receiving application, 
the gateway SHOULD..."? Maybe it's that I've been a document editor, 
but I don't think we need to micro-manage St. Peter's sentence 
structure unless we really think that a reader isn't going to 
understand. "You need detailed knowledge to pass it along; therefore, 
you SHOULD not do so" seems clear enough to me.

pr
--

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 1 comment |
headers
Peter Saint-Andre | 4 May 2004 17:36

Re: FW: DISCUSS: draft-ietf-xmpp-cpim

So if this text seems fine, I will submit an updated I-D.

Peter

On Mon, May 03, 2004 at 09:43:44PM -0500, Pete Resnick wrote:
> On 5/3/04 at 8:36 PM -0600, Joe Hildebrand wrote:
> 
> >How about just another clause, then, that says something like:
> >
> >unless the gateway can determine that the receiving entity can 
> >support an equivalent XMPP mechanism that it can translate into, the 
> >gateway SHOULD...
> 
> Isn't that what the previous sentence says?
> 
> "Because the mandatory-to-recognize feature would be required of the 
> XMPP receiving application rather than the XMPP-CPIM gateway itself, 
> the gateway cannot properly handle the 'Require' header without 
> detailed knowledge about the capabilities of the XMPP receiving 
> application."
> 
> Do we really think it needs to say, "unless you have the detailed 
> knowledge about the capabilities of the XMPP receiving application, 
> the gateway SHOULD..."? Maybe it's that I've been a document editor, 
> but I don't think we need to micro-manage St. Peter's sentence 
> structure unless we really think that a reader isn't going to 
> understand. "You need detailed knowledge to pass it along; therefore, 
> you SHOULD not do so" seems clear enough to me.
> 
> pr
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Hildebrand | 4 May 2004 17:37

RE: FW: DISCUSS: draft-ietf-xmpp-cpim

The difference is that it might not be apparent to a reader of the CPIM
draft that there exist ways for the gateway to determine client
capabilities, since those have been out-of-scope for IETF work.

That being said, I'm fine with existing text.

-- 
Joe Hildebrand

> -----Original Message-----
> From: Pete Resnick [mailto:presnick <at> qualcomm.com] 
> Sent: Monday, May 03, 2004 8:44 PM
> To: Joe Hildebrand
> Cc: xmppwg <at> jabber.org; Peter Saint-Andre
> Subject: Re: [xmppwg] FW: DISCUSS: draft-ietf-xmpp-cpim
> 
> On 5/3/04 at 8:36 PM -0600, Joe Hildebrand wrote:
> 
> >How about just another clause, then, that says something like:
> >
> >unless the gateway can determine that the receiving entity 
> can support 
> >an equivalent XMPP mechanism that it can translate into, the gateway 
> >SHOULD...
> 
> Isn't that what the previous sentence says?
> 
> "Because the mandatory-to-recognize feature would be required 
> of the XMPP receiving application rather than the XMPP-CPIM 
> gateway itself, the gateway cannot properly handle the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Saint-Andre | 4 May 2004 17:58

Re: FW: DISCUSS: draft-ietf-xmpp-cpim

On Tue, May 04, 2004 at 09:37:29AM -0600, Joe Hildebrand wrote:

> The difference is that it might not be apparent to a reader of the CPIM
> draft that there exist ways for the gateway to determine client
> capabilities, since those have been out-of-scope for IETF work.

I think we can talk about gateway knowledge of client capabilities in a
future specification or an implementation guidelines document.

> That being said, I'm fine with existing text.

OK, I will take that as +1 and submit draft-ietf-xmpp-cpim-05.

Peter
Permalink | Reply | 0 comments |

Gmane