Re: [salud] WGLC of draft-ietf-salud-alert-info-urns-09

Laura Liess <laura.liess.dt@googlemail.com> Thu, 16 January 2014 13:01 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 60B9F1AE31D for <salud@ietfa.amsl.com>; Thu, 16 Jan 2014 05:01:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 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_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 GWJvk8jZ7BjN for <salud@ietfa.amsl.com>; Thu, 16 Jan 2014 05:01:26 -0800 (PST)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DE3E01AE317 for <salud@ietf.org>; Thu, 16 Jan 2014 05:01:25 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id hr13so471112lab.29 for <salud@ietf.org>; Thu, 16 Jan 2014 05:01:10 -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=BPuf+phKfuf59f3/JmVZOFTZrtlFxBM8ZU0H1/ccoSw=; b=P3qh3hvg+j5QWBtimKQu+oohLIL50B8JRYbXtJWcBlxInmvBUoxRz20RM6PJdCRO2H 7icIogIw6symbvVvu/gPep4n2Vf1cHOI/PG1p9YMJFYknP29D3qYEC27cb6nOnHdHX+1 HLtueLzWjQfsxjfzIMskUZK5lzMLPzMmiC1L0KUixKfapEzLxLGi7Gb1AcNwConszlig zB5vwMnVlZ7djOopyzEXnw9nfT1C7dlJao+T1dxl8+SKjObnrQj9ew5ejWMZcegxF+TU U4JO1vbRAn1f0lTaDCtk2rCgPOnYo+FJupSmAJIytJPERUzcYL5qPcINepXZgLH28C/6 x47A==
MIME-Version: 1.0
X-Received: by 10.112.171.135 with SMTP id au7mr4913435lbc.10.1389877269195; Thu, 16 Jan 2014 05:01:09 -0800 (PST)
Received: by 10.114.169.129 with HTTP; Thu, 16 Jan 2014 05:01:09 -0800 (PST)
In-Reply-To: <201401072007.s07K7pCj2344695@shell01.TheWorld.com>
References: <201311201944.rAKJiS7d5355422@shell01.TheWorld.com> <528D41F2.8090200@alum.mit.edu> <201401072007.s07K7pCj2344695@shell01.TheWorld.com>
Date: Thu, 16 Jan 2014 14:01:09 +0100
Message-ID: <CACWXZj20cRsA4hdC8c1BJ=XSOVA2e6m=h6Y-e=6HB4sdhWJJHg@mail.gmail.com>
From: Laura Liess <laura.liess.dt@googlemail.com>
To: "Dale R. Worley" <worley@ariadne.com>
Content-Type: multipart/alternative; boundary=001a11c36ae4e9714404f0160443
Cc: "salud@ietf.org" <salud@ietf.org>
Subject: Re: [salud] WGLC 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: Thu, 16 Jan 2014 13:01:28 -0000

Dale,

Please see in-line.


>
> > Section 4:
> >
> >        Registration date:  TBD
> >
> > How is this to be filled in? Should there be instructions to the editor?
>
> The common method (e.g., draft-cardona-cablelabs-urn-02.txt) seems to
> be:
>
>         Registration date: YYYY-MM-DD [RFC Editor: Please replace YYYY-
>         MM-DD with the publication date of this RFC.]
>

I agree and changed the draft accordingly.


>
> > Section 11:
> >
> >     A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header
> >     field in a SIP request or a provisional 1xx response (excepting a 100
> >     response) when it needs to provide additional information about the
> >     call or about the provided service.
> >
> > I think we would ideally allow a proxy to modify/remove URNs, but 3261
> > doesn't permit that. But a proxy can get a similar effect by putting a
> > counteracting URN earlier in the sequence. But it is also possible that
> > there will be no Alert-Info and the proxy needs to add one. I suggest:
> >
> >     A SIP proxy MAY add an Alert-Info header field if none is present,
> >     and MAY add or remove URNs to an Alert-Info header
> >     field in a SIP request or a provisional 1xx response (excepting a 100
> >     response) when it needs to provide additional information about the
> >     call or about the provided service.
>
> There is complexity because we don't really care whether a URN is
> added to an existing Alert-Info or whether a new Alert-Info is
> inserted containing the URN.  I looked up the terminology in RFC 3261,
> and it isn't quite what I thought it was:
>
>       Header Field: A header field is a component of the SIP message
>          header.  A header field can appear as one or more header field
>          rows. Header field rows consist of a header field name and zero
>          or more header field values. Multiple header field values on a
>          given header field row are separated by commas. Some header
>          fields can only have a single header field value, and as a
>          result, always appear as a single header field row.
>
>       Header Field Value: A header field value is a single value; a
>          header field consists of zero or more header field values.
>
> (There is no separate definition of "header field row".)
>
> So a "header field value" is (in our case) a single URN, a "header
> field row" is one of those things starting with "Alert-Info:"
> containing one or more URNs, and the Alert-Info "header field" is the
> abstract array of all of all the URNs.
>
> Also, it seems to be understood that a proxy can reorganize how a
> header field is split into header field rows, and can reorder how the
> header field rows for one field name are ordered with respect to the
> header field rows of another field name.  (RFC 3261 section 7.3 and
> section 16.6 step "copy request") But this is not stated very clearly.
>
> Based on that, the first sentences you've listed under section 10 and
> section 11 are correct, in that we mean that the UA or proxy can add
> URNs as header field values into the array of header field values, and
> we don't care how the entity organizes the Alert-Info header field
> rows as long as the header field is correct.  I think it would be
> clearer to start the sentences:
>
>      A SIP UA/proxy MAY add one or more URN header field values to the
>      Alert-Info header field ...
>
> Do we want to footnote "header field" with "RFC 3261 section 6", which
> contains the definitions I have quoted?
>

I think the text proposed by Paul is clear enough and I would not insert
any additional explanations.

Thank you
Laura


>
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>