Re: [Aggsrv] understanding the scope of "discovery"
"Andrew Biggs (adb)" <adb@cisco.com> Tue, 19 March 2013 15:22 UTC
Return-Path: <adb@cisco.com>
X-Original-To: aggsrv@ietfa.amsl.com
Delivered-To: aggsrv@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907AF21F8D5F for <aggsrv@ietfa.amsl.com>; Tue, 19 Mar 2013 08:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU7haN8tTxWG for <aggsrv@ietfa.amsl.com>; Tue, 19 Mar 2013 08:22:35 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EE91B21F8D5D for <aggsrv@ietf.org>; Tue, 19 Mar 2013 08:22:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1596; q=dns/txt; s=iport; t=1363706555; x=1364916155; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SKtlM9CltAItBbi1WqKbklEXDBzXFHx4zsrMZcCeIuU=; b=b7PJa8MFYC4ALzqdevNSXjsbWRRx+TqSiVvxONm9d6lxl6nhHoGdiql6 MmkyquXTvubrf/dLZSxJ3ZPA05h2PNbc0Sm2DIzvcdTnhtqx8BeI0Jqkd TSAts+Eo6bo6KIuxoZavM8Gi1z3LanEuVkQRBf/Pgf92ZOhGw4lmMIlDg o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAACCSFGtJV2c/2dsb2JhbABDxQ+BVxZ0giQBAQEEOj8SAQgYChRCJQIEDgUIiAyyLZAejU0LgQUxB4JfYQOnYYMKgWo+
X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="scan'208";a="189082089"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 19 Mar 2013 15:22:34 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2JFMYPP012507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 15:22:34 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.248]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 10:22:34 -0500
From: "Andrew Biggs (adb)" <adb@cisco.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Thread-Topic: [Aggsrv] understanding the scope of "discovery"
Thread-Index: AQHOI0zhdxnePYTEk0CJfRyfOYIPh5itXyoA//+0nwA=
Date: Tue, 19 Mar 2013 15:22:33 +0000
Message-ID: <4289BE64A83C6C4384EE9245D4644539237DE086@xmb-aln-x06.cisco.com>
In-Reply-To: <0D99038D-1D63-4B6E-944A-7F1EFF255F8C@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.1.130117
x-originating-ip: [10.129.24.51]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <772613667A0EC349988247E64EABC990@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "aggsrv@ietf.org" <aggsrv@ietf.org>
Subject: Re: [Aggsrv] understanding the scope of "discovery"
X-BeenThere: aggsrv@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Aggregated Service Discovery \(aggsrv\)" <aggsrv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aggsrv>, <mailto:aggsrv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aggsrv>
List-Post: <mailto:aggsrv@ietf.org>
List-Help: <mailto:aggsrv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aggsrv>, <mailto:aggsrv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Mar 2013 15:22:35 -0000
I definitely agree, it might even be worth making an explicit statement to that effect in the draft. Even in the case where the protocol being negotiated doesn't provide a means for establishing a given operational parameter, I'm wondering if we should provide any guidance on the kind of information that should be included as part of discovery. For example, should it be limited strictly to information needed to establish a connection to a service, or should implementors be free to include anything they find useful, up to and including general client configuration? On 3/19/13 7:52 AM, "Alexey Melnikov" <alexey.melnikov@isode.com> wrote: >Hi Andrew, > >IMHO, if these things are available in the protocol being negotiated, >then I think they shouldn't be returned by the aggregated service >discovery. > >On 17 Mar 2013, at 16:20, "Andrew Biggs (adb)" <adb@cisco.com> wrote: > >> I thought an interesting point raised in the BoF was the possible >>overlap of aggregated discovery with the idea of automated client >>configuration. This got me to wonder where the line ought to be drawn, >>if at all, as to the sort of information intended for inclusion in an >>aggregated service discovery document. For example, would any of the >>following be appropriate data to include in a discovery document when >>configuring a particular service? >> >> * Synchronization window (such as for calendaring). >> * Session timeout. >> * Minimum polling interval. >> * Settings defaults for client behaviors, auto sign-in, etc. >> >> Cheers, >> Andrew >
- [Aggsrv] understanding the scope of "discovery" Andrew Biggs (adb)
- Re: [Aggsrv] understanding the scope of "discover… Alexey Melnikov
- Re: [Aggsrv] understanding the scope of "discover… Andrew Biggs (adb)