Subject: [salud] Combined draft revision

From: [email-masked] (Dale R. Worley)
Date: Tue, 8 Jul 2014 16:31:03 -0400

[as an author]

I've updated the XML2RFC draft that incorporates both the "general
revisions" (update1) and the changes for "specification required"
(update3), along with one or two editorial changes.

The XML and text versions can still be obtained from

https://svn.resiprocate.org/rep/ietf-drafts/worley/draft-worley-salud-alert-info-urns-12-update1and3.txt

https://svn.resiprocate.org/rep/ietf-drafts/worley/draft-worley-salud-alert-info-urns-12-update1and3.xml

The change is that in the earlier version, some references weren't
expressed with <xref target="..."/>.

***

More importantly, I've made a set of changes to convert <provider>
values into a first-come-first-served registry.  And, of course, a
number of minor changes in wording.  These changes are based on the
"-update1and3" draft described above.  The XML and text versions can
be obtained from

https://svn.resiprocate.org/rep/ietf-drafts/worley/draft-worley-salud-alert-info-urns-12-update4.txt

https://svn.resiprocate.org/rep/ietf-drafts/worley/draft-worley-salud-alert-info-urns-12-update4.xml

You can see the diffs between the -update1and3 draft and this draft
with

https://www.ietf.org/rfcdiff?url1=http%3A%2F%2Fsvn.resiprocate.org%2Frep%2Fietf-drafts%2Fworley%2Fdraft-worley-salud-alert-info-urns-12-update1and3.txt&difftype=--html&submit=Go!&url2=http%3A%2F%2Fsvn.resiprocate.org%2Frep%2Fietf-drafts%2Fworley%2Fdraft-worley-salud-alert-info-urns-12-update4.txt

You can see the diffs between revision 12 and this draft with

https://www.ietf.org/rfcdiff?url1=draft-ietf-salud-alert-info-urns-12&difftype=--html&submit=Go!&url2=http%3A%2F%2Fsvn.resiprocate.org%2Frep%2Fietf-drafts%2Fworley%2Fdraft-worley-salud-alert-info-urns-12-update4.txt

This draft covers all the changes that we have discussed as being desirable.

***

Comments?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Jul 2014 17:49:47 -0400

Dale,

I'm reviewing now.

Will you be coming to Toronto? I assume not. But it is closer, so maybe 
you could wangle it. You could talk to the ADs and ask if they can get 
some things covered for you to make it more feasible. They can almost 
certainly comp the registration fee. And Toronto is drivable.

	Best wishes,
	Paul

On 7/8/14 4:31 PM, Dale R. Worley wrote:
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Jul 2014 18:16:21 -0400

Hi Dale,

This is looking good.

A couple of little things:

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?

I noticed a misspelling in here. s/altert/alert/

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 9 Jul 2014 14:17:58 -0400

> From: Paul Kyzivat <[email-masked]>

> 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:[email-masked]>

   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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Jul 2014 18:38:40 -0400

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

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 10 Jul 2014 17:02:06 -0400

[as an author]

I don't see the restriction being a problem now, as we're waiting to
hear from Laura.

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

[as chair]

I do believe we should, although the technical content of these
changes was posted some time ago, and we haven't heard anything about
it.

Dale

---

From: Laura Liess <[email-masked]>
Date: Tue, 15 Jul 2014 09:52:45 +0200

Dale,

Sorry for answering so late. I read now the draft and the diffs and the
changes look good to me.

I don't think we can get it done without another WGLC. Maybe we can get an
informational feedback on the changes from Alissa and Barry, who required
the main change, already before or during the WGLC. What do you think?

Thank you
Laura

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 17 Jul 2014 17:16:19 -0400

[as an author and also as chair]

> From: Laura Liess <[email-masked]>
> 
> I read now the draft and the diffs and the changes look good to me.

If the proposed new version looks good to you (and it looks good to
both Paul and myself), since you're the editor, could you submit it as
the -13?

After that, I can (as an author) write up responses to the ADs easily
enough, and I can (as chair) start the WGLC.

Dale

---

From: Laura Liess <[email-masked]>
Date: Fri, 18 Jul 2014 08:52:05 +0200

Dale,

Yes, the new version looks good to me ( I already sent you this feedback on
the new version)  and I will submit it in Toronto, late on Sunday or on
Monday morning. The submission tool reopens on Sunday but I am flying on
Sunday to Toronto and will arrive there quite late.(I am currently quite
ill with a pneumonia but I still hope to make it to the meeting in Toronto.

Thank you
Laura

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 18 Jul 2014 14:12:12 -0400

> ill with a pneumonia but I still hope to make it to the meeting in Toronto.

I am very sorry to hear that you are ill.  (It has been clear that
recently you've been burdened by some problem.)

Your plan is a good one.  At the beginning of the this week, I was
considering that we might get Richard to allow submission during the
blackout period, but now that it is Friday, it is not worth that
effort.

[as an author]

Since all the primary authors agree on this version, I will start
preparing responses to the ADs.

Dale