Subject: [salud] Next steps for Alert-Info URN draft

From: Laura Liess <[email-masked]>
Date: Tue, 24 May 2011 15:54:40 +0200

Hi,

Two weeks ago, I submitted a new version for the draft according to
the comments I received for the requirements and use cases sections
during the mini-last-call.initiated by Dale.  I did nor received any
more comments on the last version submitted.  Can we now consider the
sections 1 to 3 as agreed ?

Thanks
Laura

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 2011/5/11
Subject: [salud] I-D Action:draft-ietf-salud-alert-info-urns-02.txt
To: [email-masked]
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sip ALerting for User Devices Working
Group of the IETF.

       Title           : Alert-Info URNs for the Session Initiation
Protocol (SIP)
       Author(s)       : L. Liess, et al.
       Filename        : draft-ietf-salud-alert-info-urns-02.txt
       Pages           : 24
       Date            : 2011-05-11

The Session Initiation Protocol (SIP) supports the capability to
provide a reference to a specific rendering to be used by the UA when
the user is alerted.  This is done using the Alert-Info header field.
However, the reference addresses only network resources with specific
rendering properties.  There is currently no support for predefined
standard identifiers for describing the semantics of the alerting
situation or the characteristics of the alerting signal, without
being tied to a particular rendering.  To overcome this limitation
and support new applications, a new family of URNs for use in SIP
Alert-Info header fields is defined in this specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-salud-alert-info-urns-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
salud mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/salud

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 24 May 2011 23:05:52 -0400

[as individual]

________________________________________
From: Laura Liess [[email-masked]]

They look good to me.  I've got a few purely editorial comments, but
addressing them should not delay the technical work.

Section 1.3 reproduces a lot of terminology I introduced at one point
in the discussion, but is probably not useful any more.

REQ-5 uses the words "category" and "categories", which were
introduced in section 1.3.  But looking at REQ-3, those words should
be changed to "characteristic" and "characteristics". (There may be
other places where obsolete terminology from 1.3 has leaked into the text.)

In REQ-8, I think the words "of" and "in" (as capitalized below)
should be swapped, to give:

   REQ-8: The mechanism will allow transmission OF the Alert-Info header
   field IN SIP INVITE requests and provisional 1xx responses excepting
   the 100 responses.

Dale

---

From: Laura Liess <[email-masked]>
Date: Wed, 25 May 2011 15:31:26 +0200

Dale,

Thank you for the comments. Please see inline.

> [as individual]
[LL] I would rather try to  finish the sections 1 to 3 completely (I
hope it just a matter of days),  before we continue with the rest.
> other places where obsolete terminology from 1.3 has leaked into the text.)

[LL] Many people's opinion at that time was that a Terminology section
is usefull. It was my opinion, too. I still think it is usefull. Maybe
not for those involved in the discussions, but for those  reading the
document for the first time. Also people already reviewed Sections 1
to 3. If we change or delete the Terminology section, sections 2 and 3
need at least one additional review cycle.  I wouldn't make this
change without asking first all them who already reviewed the
document.

My understanding is that you consider section 1.3  as eventually not
useful, but not wrong. My opinion is to leave it as it is, there is no
harm in it.  What do you think?

>   field IN SIP INVITE requests and provisional 1xx responses excepting

[LL] Yes, thanks.

Thank you
Laura

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 25 May 2011 11:53:51 -0400

It may well be that a terminology section is useful.  But I suspect that section 1.3 as it stands
is not a particularly good version.  I wrote it fairly quickly, and the rest of the document does
not follow it faithfully.

But I don't think that problem needs to be solved immediately.  Often as the discussion of
the technology progresses, one discovers that changing the terminology would be helpful.
We should consider "making the terminology consistent" as one of the later phases of
updating the draft.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 25 May 2011 11:58:31 -0400

[as individual]

> It may well be that a terminology section is useful.  But I suspect
> that section 1.3 as it stands is not a particularly good version.  I
> wrote it fairly quickly, and the rest of the document does not follow
> it faithfully.
> 
> But I don't think that problem needs to be solved immediately.  Often
> as the discussion of the technology progresses, one discovers that
> changing the terminology would be helpful.  We should consider "making
> the terminology consistent" as one of the later phases of updating the
> draft.

Dale

---

From: Laura Liess <[email-masked]>
Date: Thu, 26 May 2011 16:50:25 +0200

Dale,
I am fine with this proposal.

The question now is on the next steps and how to proceed about the
more critical issues: single vs. multiple URNs, combinations of URNs,
priority and extensibility rules. Discuss them on the ML or do we need
a Webex?  What is your opinion?

Thanks
Laura

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 31 May 2011 15:47:47 -0400

[as individual]

First, let us try to list all the open technical issues on the mailing list.  The issues that I know of are:

- Shall we combine all the characteristics into one URN (leading to a very large set of possible URNs), or specify each characteristic in a separate URN (and have the UA combine them)?

- In regard to extensibility, shall we arrange for each characteristic value to be subdividable into more narrowly-defined values, which are themselves subdividable, etc.?

- In regard to extensibility, what proprietary or non-standard extensions will be possible?

- How will non-standard extensions be designated?  (Will they be consistently marked by a particular prefix?  Will they be constructed from domain names?)

- How does the "legacy" URN <urn:alert:service:normal> fit into the new system?

Dale