Re: [Simple] Consensus Call on draft-ietf-simple-chat

"Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com> Fri, 17 December 2010 08:35 UTC

Return-Path: <miguel.a.garcia@ericsson.com>
X-Original-To: simple@core3.amsl.com
Delivered-To: simple@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70A483A6ABE for <simple@core3.amsl.com>; Fri, 17 Dec 2010 00:35:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QyNTEn9NP2R for <simple@core3.amsl.com>; Fri, 17 Dec 2010 00:35:57 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E6C4B3A6ABD for <simple@ietf.org>; Fri, 17 Dec 2010 00:35:56 -0800 (PST)
X-AuditID: c1b4fb3d-b7b89ae0000036a3-ea-4d0b21550fe4
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E9.1D.13987.5512B0D4; Fri, 17 Dec 2010 09:37:41 +0100 (CET)
Received: from [159.107.48.189] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Fri, 17 Dec 2010 09:37:40 +0100
Message-ID: <4D0B2153.8010708@ericsson.com>
Date: Fri, 17 Dec 2010 09:37:39 +0100
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 ThunderBrowse/3.3.4
MIME-Version: 1.0
To: Ben Campbell <ben@estacado.net>
References: <FBBFFFB0-E69E-4236-90EC-54623C6FAF80@nostrum.com> <AANLkTikOpUstFvPnmYc4y56KrOFx96GwBDq9XL2=zVk_@mail.gmail.com> <C3636304-F20A-42A0-A0E1-F18ACEB268A8@nostrum.com> <3A9BAD1F-1C2E-4507-88E6-08035CB05081@estacado.net>
In-Reply-To: <3A9BAD1F-1C2E-4507-88E6-08035CB05081@estacado.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: Adam Roach <adam@nostrum.com>, Geir Arne Sandbakken <geir.sandbakken@tandberg.com>, Simple WG <simple@ietf.org>, "xcon-chairs@tools.ietf.org" <xcon-chairs@tools.ietf.org>, Mary Barnes <mary.ietf.barnes@gmail.com>, Aki Niemi <aki.niemi@nokia.com>
Subject: Re: [Simple] Consensus Call on draft-ietf-simple-chat
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Dec 2010 08:35:58 -0000

I was checking the Instructions to RFC Authors, 
http://www.rfc-editor.org/rfc-editor/instructions2authors.txt

I was trying to understand if the reference to XCON Common Data Model 
should be normative or informative. According to the RFC Editor document,

                                                     Normative references
       specify documents that must be read to understand or implement the
       technology in the new RFC, or whose technology must be present for
       the technology in the new RFC to work.  An informative reference
       is not normative; rather, it provides only additional information.
       For example, an informative reference might provide background or
       historical information.  Material in an informative reference is
       not required to implement the technology in the RFC.

As you can see, the distinction between normative and informative lies on 
the importance of the referred document for the implementation of the 
technology, not on whether the referred document is an optional 
implementation or not.

Given that, I believe that someone wanted to implement the simple-chat 
draft, and in particular, the option to learn nicknames through the 
extension to the conference package, should do at least a partial 
implementation of the XCON Common Data Model, in which case, the 
reference to the XCON Common Data Model must be normative.

So, in case I was not clear enough.

I agree with 1).

Option 2) should be a normative reference to RFC 4575.

I agree with 3). I am not sure what "informational reference" means here 
again, presumably you mean a non-normative text indicating a possible way 
to learn nicknames. I agree with that.

BR,

        Miguel

On 16/12/2010 22:19, Ben Campbell wrote:
> Oh, and I forgot to put in my answers to the proposal consensus call: Yes
> on all 3.
>
> I can live with both references being normative if people want that, but
> concur with Geir's other post--I don't think we're making any normative
> requirement to use the event-package.
>
> On Dec 16, 2010, at 11:19 AM, Ben Campbell wrote:
>
>> (as individual)
>>
>> On Dec 16, 2010, at 11:04 AM, Mary Barnes wrote:
>>
>>> I would agree with option 1, but I do not think you can have the
>>> 'nickname' defined in an informational draft so options 2) and 3) are
>>> not good IMHO. Nickname is a key data element for chats. So, I would
>>> suggest you add a fourth option and that is to add a normative
>>> reference to the xcon-data-model.
>>
>> The informational part was not to say an informational draft, but an
>> informational reference. I think the approach under discussion was to
>> say that you MAY convey nickname information. One possible way to do
>> that is with draft-ietf-xcon-common-data-model. I don't have a strong
>> objection to making that a normative reference, though, if that is what
>> others prefer.
>>
>>
>>> Of course, that doc will be published right around the same time as
>>> CCMP and per the draft-boulton-xcon-session-chat, you will have a chat
>>> based mechanism that doesn't require extensions to MSRP. Although, in
>>> cases where folks might first implement this mechanism for chat
>>> (rather than XMPP, for example) and later want to use this mechanism
>>> with XCON, it would still work - it's just that you'd have two
>>> different mechanisms for setting the nickname.
>>
>> Yep. That's come up before, and each time we land on "lets go ahead and
>> publish simple-chat". I don't expect a different answer this time
>> (although if someone has actually changed their mind since last time,
>> I'd love to hear it.)
>>
>>> Regards,
>>> Mary.
>>> On Thu, Dec 16, 2010 at 10:36 AM, Ben Campbell <ben@nostrum.com
>>> <mailto:ben@nostrum.com>> wrote:
>>>
>>>     (as chair)
>>>
>>>     Hi,
>>>
>>>     I discussed this with a number of people individually, but I don't
>>>     think we ever brought this to the SIMPLE list, so I want to make
>>>     it official. I've copied the XCON chairs, as well as people I
>>>     recall discussing this with.
>>>
>>>     In reviewing draft-ietf-simple-chat prior to requesting
>>>     publication, we ran across the fact that this draft extended the
>>>     data format from RFC 4575 (sip event package) in order to add a
>>>     "nickname" data element. The issue was that RFC 4575 did not
>>>     define a clear way to add new data elements, so this would appear
>>>     to require an update to that RFC.
>>>
>>>     OTOH, XCON produced draft-ietf-xcon-event-package and
>>>     draft-ietf-xcon-common-data-model in order to extend RFC 4575 with
>>>     a richer data set. The former is in the RFC Editor queue, and the
>>>     latter is in AD Followup. These drafts extend the SIP conference
>>>     model with a richer data format. My understanding is that
>>>     draft-ietf-xcon-common-data-model includes the "nickname" element,
>>>     and is otherwise a superset of the format in RFC 4575.
>>>
>>>     We have a proposal to change draft-ietf-simple-chat as follows:
>>>
>>>     1) Remove the update to RFC 4575
>>>
>>>     2) Demote the reference to RFC 4575 to informational.
>>>
>>>     3) Add an informational reference to
>>>     draft-ietf-xcon-common-data-model as a possible way to convey
>>>     "nickname" information to conference package subscribers.
>>>
>>>     Please respond indicating whether you agree with some or all of
>>>     the above, along with any rational you would like to share. I
>>>     don't think these are all or nothing--for example one might agree
>>>     with 3 but disagree with 1 or 2.
>>>
>>>     We'd really like to get submit this draft prior to the end of the
>>>     year, and I think this is the last blocking item, so please
>>>     respond ASAP.
>>>     _______________________________________________
>>>     Simple mailing list
>>>     Simple@ietf.org <mailto:Simple@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/simple
>>>
>>>
>>
>> _______________________________________________
>> Simple mailing list
>> Simple@ietf.org <mailto:Simple@ietf.org>
>> https://www.ietf.org/mailman/listinfo/simple
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain