Re: [Rum] draft-ietf-rum-rue-02.txt

[Paul Kyzivat <[e-mail]>]

Here are some further comments on -02:

This update has largely expunged separate specifications for the RUE and 
the provider server the RUE connects to in favor of talking about the 
RUE Interface that both are required to implement. In some cases that 
makes sense because the requirements are the same on both sides. In 
other cases it seems to dodge the issue that the two sides have 
different roles and responsibilities. For instance: RFC5626 (outbound), 
RFC6665 (events), RFC6442 (geoloc).

Section 5.2.1 now says:

    The all outbound calls MUST be routed through an outbound proxy if
    configured.

(It previously specified the RUE.) IIUC this really does only apply to 
the RUE. AFAIK we don't specify any configuration for the provider, and 
presumably providers can do whatever they want that works. (Also, the 
language is a bit messed up.)

Section 5.2.3 says:

    To identify the owner of a RUE, the initial INVITE for a call from a
    RUE, or the 200 OK accepting a call by a RUE, identifies the owner by
    sending a Call-Info header with a purpose parameter of "rue-owner".

This new purpose parameter needs to be registered with IANA. It 
currently isn't mentioned in section 11.

Section 5.2.5 says:

    The implementations comply with [RFC6881] for handling of emergency
    calls.

This is not a normative statement. AFAICT there is no normative 
requirement to support this. And this is another asymmetric case. (IIUC 
the provider need not include GeoLoc in outbound calls to the RUE.)

This section also uses "client" and "server" to refer to the RUE and 
Provider sides of a RUE Interface. This differs from using "client" to 
refer to UAC and "server" for UAS.

Section 5.5 and elsewhere use the following construction:

    Implementations MUST conform to ... with the understanding that ...

That language seems a bit vague to me. Is this relaxing any normative 
statements in the reference, or simply stating that only a subset of the 
standard will be used in practice? I'd like to see this tightened up 
normatively.

Section 6.3:

I think this is saying that RUEs MUST support VP8 unless they can't, 
while providers MUST *support* VP8 but need not use it in every call, 
such as when connecting to another endpoint that doesn't. I get the 
spirit, but it fails to make clear when an implementation is non-conforming.

For instance, is it acceptable for a provider's interpreters to use 
non-RUE devices that don't support VP8? Is it acceptable for the 
provider video-mail server to not support VP8?

Section 8:

IIUC this means that the provider may or may not include a "mwi" entry 
in the configuration, but if it is configured that both sides are 
required to support it as specified.

Section 9.1:

This makes it optional for a RUE to make the choice of provider 
available to the user. Is that what we want?

Section 9.3:

These schemas use the [JCR] notation. This dates back to the early 
versions of this document several years ago. At the time there was 
single accepted schema notation for JSON. JCR was under development at 
the time. I haven't kept up with what has been happening with JSON 
schemas. I just looked and it appears that 
draft-newton-json-content-rules-09 is the latest version of JCR. I don't 
know if that means it was abandoned in favor of something else. We need 
to investigate this.

	Thanks,
	Paul