ietf
[Top] [All Lists]

RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

2010-04-05 14:56:02
On Mon, 2010-04-05 at 15:09 -0400, Hadriel Kaplan wrote:

-----Original Message-----
From: Scott Lawrence [mailto:xmlscott(_at_)gmail(_dot_)com]
Sent: Monday, April 05, 2010 2:30 PM
To: Hadriel Kaplan

The spec says in section 2.6
(Validity of Stored Configuration Data):

        The UA MAY use configuration data that is of unknown validity,
        or configuration data that is known to be no longer valid, while
        attempting to revalidate that data or obtain new data.

So the UA may use the configuration data before any subscription is
established - the subscription does not block anything (except getting
change notices).

Heh... weren't you just arguing about how optional requirements in
IETF docs are bad?  ;)

This form of optional is right up that alley.  For example, if I am a
service provider who wants to not have Subscription mode, and the only
way to do it is through UA config framework itself by setting a config
field for "Subscribe-UA-Config="false" or whatever, then clearly the
UA's MUST use the config.  A MAY statement does nothing.

The draft is clear that the configuration data can modify any part of
the procedures in the draft.  Section 2:

        The User Agent MAY obtain configuration information by any means
        in addition to those specified here, and MAY use such
        information in preference to any of the steps specified
        below, ...
        
So if you're looking for an escape clause, you've found it, but the rest
of the sentence is important

        ...but MUST be capable of using these procedures alone in order
        to be compliant with this specification.

If it's not clear and exact as to what config data a UA is supposed to
use, and when, then you really do get "flaky service behavior" as you
were worried about in a previous email.

I think that the wording of that particular statement is perhaps
unfortunate, but have not found a better one.  In effect, what we were
trying to do is express that the UA is not required to wait until the
subscription exists to use the data, and can continue to use the data
should the subscription fail for any reason.  This prevents various
failure modes and/or delays in the UA when the Configuration Service is
overloaded or otherwise unavailable.  It's not an 'optional requirement'
it's a non-requirement.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>