Re: [salud] Combined draft revision

[Paul Kyzivat <[e-mail]>]

This all sounds good. Unfortunately you can't submit it until the 
meeting begins. This is a really silly restriction when the wg isn't 
even meeting.

Maybe the ADs would override and allow it to be submitted.

Unfortunately, I think this really needs another WGLC. :-)

	Thanks,
	Paul

On 7/9/14 2:17 PM, Dale R. Worley wrote:
>> From: Paul Kyzivat <[e-mail]>
>
>> Section 10.1 says:
>>
>>      Extensions, either standard or private, MUST conform to the
>>      following principles:
>>
>> This is certainly right for standard extensions. The expert reviewer
>> enforces this. For private extensions, can we be normative? We want to
>> be, but is that imposing constraints on people rather than code?
>
> We're imposing a constraint on the URNs that go over the wire and
> their meanings, but it is people who create URNs.
>
> We had a similar situation in the -12 version, where less-explicit
> principles were stated that implicitly applied to private extensions.
>
>> I noticed a misspelling in here. s/altert/alert/
>
> I just ran a spell checker over it.  There is also
> s/availiable/available/.  I've checked in that change as part of
> -update4.
>
> I have also just added a paragraph to section 14, "Proxy Behaviour",
> to explain *why* a proxy would want to modify Alert-Info.  I think all
> of the examples I list are in the draft already in other places, so
> this is just a writing change:
>
>     14.  Proxy Behaviour
>
>     A SIP proxy MAY add an Alert-Info header field if none is present,
>     and MAY add or remove header field values of an Alert-Info header
>     field in a SIP request or a provisional 1xx response (excepting a 100
>     response) when it needs to modify the information about the call or
>     about the provided services.
>
> +  There are many reasons a proxy may choose do this.  For example: (1)
> +  to add indications based on information that the proxy can determine
> +  about the call, such as that it is coming from an external source, or
> +  that the INVITE contains a "Priority: urgent" header field; (2) to
> +  add indication that a particular service is being invoked at this end
> +  of the call; (3) to remove undesirable indications, such as possibly
> +  deceptive indications from untrusted sources; and (4) to remove
> +  indications that contain information that should be suppressed for
> +  privacy reasons.
>
>     The following example shows a typical example of a 180 (Ringing)
>     ...
>
> Some changes in -update4 that I'd like to mention:
>
> I've reformatted the following text in the Introduction.  But I've
> also replaced "normal" with "external" wherever it appears, because
> the previous examples all used "normal" in the Alert-Info URLs.  I
> assume that these examples do not have to match the behavior of any
> real product, so we can adjust the examples to improve clarity.
>
>     The issues with URLs that reference audio files can be avoided by
>     using fixed URLs with specific meanings.  However this approach has
>     its own interoperability issues.  For example, consider the PBX
>     special ring tone for an external (to the PBX) caller.  Different
>     vendors use different approaches such as:
>
>        Alert-Info: <file://ring.pcm>;alert=external
>
>     where ring.pcm is a dummy file name, or:
>
>        Alert-Info: <file://external.ring.pcm>
>        Alert-Info: <sip:[e-mail]>
>
>     As a result, the Alert-Info header field currently only works when
>     the same vendor provides PBX and UA, and only then if the same
>     artificial proprietary URI convention used.
>
> Now that we've added a subsection to section 4 ("Updates to RFC 3261")
> to state "Proxies May Alter Alert-Info Header Fields", I've
> reformatted it into two subsections, one for each normative change.
> Since Christer was particularly interested in stating the normative
> changes, he should check whether this is done well.
>
> In the Requirements, there are two uses of the sentence "Use cases and
> values definition are not a subject of this specification."  In
> previous versions, the sentence ends "... are not subject of this
> specification".  The usual way to say this in RFCs is the awkward
> phrase "... is outside the scope of this specification".
>
> Unfortunately this use of "subject" isn't within the dictionary
> meaning of "subject" -- I suspect it is a direct translation of a
> German expression (which is much clearer than the English "outside the
> scope").  I've added the word "a" to turn this into "Use cases and
> values definition are not a subject of this specification."  This
> isn't quite as nice as using "subject" as a verb, but it's correct
> according to the dictionary and reads smoothly.  I would like to see
> this become the conventional way of expressing this meaning in RFCs.
>
> The English modifier "more than one" must be followed by a singular
> noun.  That is actually quite peculiar, because the *meaning* is
> necessarily plural.
>
> Dale
>