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

Laura Liess <laura.liess.dt@googlemail.com> Wed, 22 January 2014 13:39 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 A76161A00F7 for <salud@ietfa.amsl.com>; Wed, 22 Jan 2014 05:39:40 -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 KdciiMcJskY2 for <salud@ietfa.amsl.com>; Wed, 22 Jan 2014 05:39:38 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BEC701A00D6 for <salud@ietf.org>; Wed, 22 Jan 2014 05:39:37 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id b8so323491lan.32 for <salud@ietf.org>; Wed, 22 Jan 2014 05:39:36 -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=loKf/WtvPPq17XRX9wvnzDuqau6UfU+4hhXlBTbfoiE=; b=IIaZeqv9PeyiOvAD6TF5MvKYjRJvJhLZwmhzFVvYDScz2yO1Fq9kJNZENUEOUyA2zd KvY83oBzi7xIxVXk37TOptZIMv3KmyhS47T9DmMgv7Q6m5oRf5Rx0GYzRuwxXirv3tpt NxvkjywF5UqeDtqWQm9GTYwX3O1hbn5CsdPzMLp3D+4xBgloJ5PWHdlbx5hcEamlO64J RuNfrtkxv4cRyBcCjWurzX7n6U3xtQ6QGQqeAOF1/iBSCm1tx9S56qySHEZodaC+BRAC Jyzvbj9uL9T4JckCsyxSoV8cW7aJlcaYSrjjvwfvBQdMWtXInv4ckJDjSs2u5jk/X7vF OkEQ==
MIME-Version: 1.0
X-Received: by 10.112.157.234 with SMTP id wp10mr1121192lbb.50.1390397976509; Wed, 22 Jan 2014 05:39:36 -0800 (PST)
Received: by 10.114.169.129 with HTTP; Wed, 22 Jan 2014 05:39:36 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1120FE@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> <CACWXZj33UCV7miz4FE=SHnmaPp0BdpZCR3b3bh8AZxjv0ruCug@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1120FE@ESESSMB209.ericsson.se>
Date: Wed, 22 Jan 2014 14:39:36 +0100
Message-ID: <CACWXZj2z536sqHgc3iRZrr5XXFZs9c8Dv6JgK3RUS1GM_12kUQ@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=001a11c26b127c81b204f08f4130
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: Wed, 22 Jan 2014 13:39:40 -0000

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

>  Hi,
>
>  In my opinion, the normative update (no matter how is done), should not
> be in section 1, which is introduction.
>
>  It shall of course be mentioned there, but I still think there should be
> a dedicated “Update to RFC 3261” section.
>
That is what I intend to do. New Section 2  "Update to RFC 3261", exactly
as you proposed with the subsections 2.1 "General"  and 2.2 "New text
replacing ....".
My question is about the content of the subsection 2.1 "General". The
current section  1.2 contains three paragraphs. I propose to put into 2.1
only the first two paragraphs from the current 1.2 and to move the third
paragraph to section 1.1 because this paragraph does not describe an update
of the 3261.  Would you agree with this change?

Thank you
Laura


Regards,
>
>  Christer
>
>  Sent from Windows Mail
>
>   *From:* laura.liess.dt@googlemail.com
> *Sent:* ‎Tuesday‎, ‎January‎ ‎21‎, ‎2014 ‎3‎:‎30‎ ‎PM
> *To:* Hans-Christer Holmberg <christer.holmberg@ericsson.com>
> *Cc:* salud@ietf.org
>
>   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
>>
>>
>