Re: [salud] Christer's review of draft-ietf-salud-alert-info-urns-09

Laura Liess <laura.liess.dt@googlemail.com> Tue, 21 January 2014 13:30 UTC

Return-Path: <laura.liess.dt@googlemail.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8D11A00CE for <salud@ietfa.amsl.com>; Tue, 21 Jan 2014 05:30:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.396
X-Spam-Level:
X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAoD5suwGkIZ for <salud@ietfa.amsl.com>; Tue, 21 Jan 2014 05:30:19 -0800 (PST)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 00C701A00CC for <salud@ietf.org>; Tue, 21 Jan 2014 05:30:18 -0800 (PST)
Received: by mail-lb0-f170.google.com with SMTP id u14so5916049lbd.15 for <salud@ietf.org>; Tue, 21 Jan 2014 05:30:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/yQ60D0cJZvrk+zGmTJnD1BQzVXhWsFNPB5U8rSYoQI=; b=a3pMAbXPrQpXhDrS2J+FTaB+hJ/osK1PkXd3ewHTGVsEPF7qYNYUN1d2zZHhbdghqF aTMuK2YwcslAhhG4VB8Ld/cQy68lJoL9U/2ajnrvnm/tmNQ7HOWEdTwv5l4G1IQQJ14b HY1hM0JC+uQ33Dec7803r/XEk/PftqTQzi+8Iq0enI6FOjTiHJAo/XLx54sTdJzIbDTQ k4kMHuFpshkvhvrs5fJS58W4zE58jvQK6sY7oRCFxMqgAd4tcQEDjMTqEm1Kf6t1jxij MEt6JCLHBtxBJdJHcWYu9yjlNLul4X0InaD1FsG6xFzlWvjxUe/ONuE3FLtyi/2u5kRN lF/w==
MIME-Version: 1.0
X-Received: by 10.152.87.5 with SMTP id t5mr1357206laz.43.1390311018003; Tue, 21 Jan 2014 05:30:18 -0800 (PST)
Received: by 10.114.169.129 with HTTP; Tue, 21 Jan 2014 05:30:17 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D11179F@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C5EF0E7@ESESSMB209.ericsson.se> <201401072131.s07LVQZs2347719@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C5F00D5@ESESSMB209.ericsson.se> <201401162107.s0GL7AKI2944531@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1D108F92@ESESSMB209.ericsson.se> <CACWXZj033ssRvpJPQ=V8LACYUW9SpySbf+Pi86XR6eu5YWmdcw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D11179F@ESESSMB209.ericsson.se>
Date: Tue, 21 Jan 2014 14:30:17 +0100
Message-ID: <CACWXZj33UCV7miz4FE=SHnmaPp0BdpZCR3b3bh8AZxjv0ruCug@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=001a11c34cc05b015b04f07b0265
Cc: "salud@ietf.org" <salud@ietf.org>
Subject: Re: [salud] Christer's review of draft-ietf-salud-alert-info-urns-09
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>, <mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/salud/>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>, <mailto:salud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 13:30:22 -0000

Hi Christer,

thank you. What about moving the third paragraph to subsection 1.1?  Could
this work for you?

Laura


2014/1/21 Christer Holmberg <christer.holmberg@ericsson.com>

>  Hi Laura,
>
>  SIPCORE some time ago decided not to use/maintain the header field
> tables anymore, so that is why I didn't include it in my change suggestion.
>
>  But, if you want to also change the table, I won’t object 😊
>
>  Regards,
>
>  Christer
>
>  Sent from Windows Mail
>
>   *From:* laura.liess.dt@googlemail.com
> *Sent:* ‎Tuesday‎, ‎January‎ ‎21‎, ‎2014 ‎12‎:‎54‎ ‎PM
> *To:* Hans-Christer Holmberg <christer.holmberg@ericsson.com>
> *Cc:* Dale R. Worley <worley@ariadne.com>om>, salud@ietf.org
>
>   Christer, Dale,
>
> IMO, the  draft updates the RFC 3261 because it allows the usage of the
> Alert-Info header field in all provisional responses 1xx except the 100
> response. This is described in the first two paragraphs of Section 1.2.
> This paragraphs are OK in this section.
> The third  paragraph is usefull (it explains what the draft does) but, as
> Christer remarked,  it does not describe the update of the RFC3261 and so
> it does not belong to this section.  I would move this paragraph at the end
> of Section 1.1. What do you think?
>
>  Concerning the structure if the Section 1.2,   I will put the text from
> section 1.2 into a new main Section 2 and structure it as Christer proposes
> in http://www.ietf.org/mail-archive/web/salud/current/msg00454.html.
> But  I think there are two places where we should update the 3261 text:
>  1) Section 20.4 as proposed by Christer and
>
>  2) Table 2: Summary of header fields, A--O on page 161, the " 180" in
> the row
>
>   Alert-Info             180     ar    -   -   -   o   -   -
>
>     should be changed in "1xx (excepting 100)"
>
>  so we probably need two subsections "New text repalcing the
> text.........of RFC 3261" .
> Opinions?
>
>  Thank you
>  Laura
>
>
>
> 2014/1/20 Christer Holmberg <christer.holmberg@ericsson.com>
>
>> Hi,
>>
>> >> BTW, the following sentence is unclear to me:
>> >>
>> >>    "In practice, this specification extends Alert-Info in that it will
>> >>    cause the use of a new class of URIs and the use of multiple URIs."
>> >>
>> >> What does it mean?
>> >
>> > The idea is that, while 3261 syntactically and semantically *allows*
>> non-HTTP URIs in Alert-Info, nobody ever used non-HTTP URIs in Alert-Info,
>> and nobody implemented an interpretation of those URIs.
>> > Thus, even though we are not changing what is officially permitted,
>> implementers will have to change their code because the new *practice* will
>> be an extension of the old practice.  (And both the new practice and the
>> old practice are a small subset of what is permitted by 3261.)
>>
>>  Well, then you should use different wording. Because, the draft does not
>> extend Alert-Info, it simply describes the usage of a new URN in the header
>> field.
>>
>>
>> >>>> Q9:
>> >>>> -----
>> >>>>
>> >>>> Section 4 defines the ABNF for the URN, but [there] is no text on
>> >>>> how to "map" it into the Alert-Info header field ABNF:
>> >>>>
>> >>>> For example, I assume that the URN is encoded using the opaque-part
>> >>>> format of the absoluteURI, and that the scheme value is "urn". I
>> >>>> think it would be good to indicate that.
>> >>>
>> >>> Actually, we're depending on the fact (unstated in RFC 3261) that
>> >>> any "absolute" URI (per RFC 3986) is allowed as a header field value
>> >>> in Alert-Info, and that the URNs we are defining conform to the
>> >>> absolute URI syntax.  If the syntax for <absoluteURI> in RFC 3261
>> >>> didn't allow all absolute URIs, we'd have to amend RFC 3261.
>> >>
>> >> There are two different "structures" for absolute URI, and the URNs
>> >> only fit into the opaque-part structure.
>> >>
>> >> In addition, as the URI requires a scheme value, I think we should
>> >> explicitly say what it is.
>> >
>> > I guess my point is that the 3261 ABNF already allows all alert URNs to
>> appear in Alert-Info, and there is no need to specify exactly how alert
>> URNs are compatible with the 3261 ABNF.  Anyone who cares exactly how this
>> draft is directly compatible with the ABNF can see that by looking at the
>> ABNF.
>> >
>> > Have there been other situations where this sort of syntax explication
>> has been provided?
>>
>>  I don't know - I am just commenting on how I think the draft could from
>> my perspective be improved :)
>>
>> Regards,
>>
>> Christer
>>  _______________________________________________
>> salud mailing list
>> salud@ietf.org
>> https://www.ietf.org/mailman/listinfo/salud
>>
>
>
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>
>