Subject: [Aggsrv] understanding the scope of "discovery"

From: "Andrew Biggs (adb)" <[email-masked]>
Date: Sun, 17 Mar 2013 20:20:35 +0000

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 19 Mar 2013 09:52:20 -0400

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.

---

From: "Andrew Biggs (adb)" <[email-masked]>
Date: Tue, 19 Mar 2013 15:22:33 +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" <[email-masked]> 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.
>
>> 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?
>>