Re: [Gen-art] Gen-ART LC review of draft-hanes-dispatch-fax-capability-06.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 07 December 2012 13:47 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E87421F8532 for <gen-art@ietfa.amsl.com>; Fri, 7 Dec 2012 05:47:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.366
X-Spam-Level:
X-Spam-Status: No, score=-101.366 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFzQHg7Aqmip for <gen-art@ietfa.amsl.com>; Fri, 7 Dec 2012 05:47:09 -0800 (PST)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5377021F8530 for <gen-art@ietf.org>; Fri, 7 Dec 2012 05:47:09 -0800 (PST)
Received: by mail-wi0-f174.google.com with SMTP id hm9so1374055wib.13 for <gen-art@ietf.org>; Fri, 07 Dec 2012 05:47:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f8Vp+ddBMr0rfuR8kyPm/VJZZSgmBSGjbG+TUvYMDOk=; b=ABf8hi2XIlYR5l3Culv3xUSVD8LL+SnTfok6nTI+tfq3W8otAFC11YZ6iNgkFQWUuy X29gOhkR6DhR/29k0ZA3Mia1wk1SoEcAL0xf2vu0NlcmJ+BaWARFhjlEFV+giwHqj0nx S8MFzlmr0UC92OK2K6bdat/EcM7ZhyDCAuqyBv9K+ulLO7ev6/zsfjS6uURliSpTF/P0 4v5BXYHDcGG4a/SP9rwP7w4BJQX/Rr1JPcE7qPUcVLYWM+vqsT4lAN+cfCwx1KnDAlG7 ZzgHscsAiyKYRII77C32oeu6QB5C/JoRRN6LRq9+ph03x6v6oDYc8wYY3tcfRHI0A5Zf lJwA==
Received: by 10.216.219.201 with SMTP id m51mr2243237wep.15.1354888028491; Fri, 07 Dec 2012 05:47:08 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-219-171.as13285.net. [2.102.219.171]) by mx.google.com with ESMTPS id h19sm21260643wiv.7.2012.12.07.05.47.06 (version=SSLv3 cipher=OTHER); Fri, 07 Dec 2012 05:47:07 -0800 (PST)
Message-ID: <50C1F369.3090805@gmail.com>
Date: Fri, 07 Dec 2012 13:47:21 +0000
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: David Hanes <dhanes@cisco.com>
References: <50BF242F.8000709@gmail.com> <CAE+Udoqd_GHaEF6h_HGVZP8AwkKMaVGygKc5sJjcr8X=SsTiKA@mail.gmail.com> <50BF3199.4000109@gmail.com> <CAE+UdoqSZ_d1xTkyrTs-9rFq2OLyo0zZaxA29pqj_fo6vfk1RA@mail.gmail.com> <50BF700A.3010402@gmail.com> <50C1B077.9050004@ericsson.com> <CAE+UdoqU1tHnfa0SMqu6XWGJY8X9rqrQ0P+mACNNZ5TU+DPaHw@mail.gmail.com> <A7FEAAB1-B211-4896-B328-59B30AC39F61@cisco.com>
In-Reply-To: <A7FEAAB1-B211-4896-B328-59B30AC39F61@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: General Area Review Team <gen-art@ietf.org>, Kevin Fleming <kevin@kpfleming.us>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, draft-hanes-dispatch-fax-capability.all@tools.ietf.org
Subject: Re: [Gen-art] Gen-ART LC review of draft-hanes-dispatch-fax-capability-06.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2012 13:47:10 -0000

Oops, that crossed with my note.

In that case maybe a small clarification *is* needed in the draft.

Regards
   Brian Carpenter

On 07/12/2012 13:19, David Hanes wrote:
> Hi Kevin,
> 
> Actually, I had just copied the draft authors on that thread and Brian was not on it. Below is Paul's response for everyone's clarification.
> 
> Thanks,
> David
> 
> 
> 
> 
> 
> On 12/6/12 12:17 PM, David Hanes wrote:
>> Hi Paul,
>>
>> I am hoping you can lend us a hand in answering a comment from Brian
>> Carpenter (attached), who is the Gen-ART reviewer for our draft. Being
>> an author of 3840 and instrumental in helping us revise our draft, you
>> seem to be the best person to comment here.
>>
>> In the thread below, Kevin proposes the question, " is a registrar even
>> allowed to return a Contact header that differs from the one the UA
>> supplied in its REGISTER request?". I think that the answer to this
>> question determines how we progress forward in addressing Brian's
>> comment. We would appreciate your thoughts and guidance on this when you
>> have a moment.
> 
> I'll try.
> 
> RFC 3261 doesn't say anything about the registrar saving or returning contact parameters, other than the expiration time and q-value.
> 
> RFC 3840 does that. *If* the registrar supports the "pref" option, then it is required to save the feature parameters (aka feature tags or capabilities), and to return them in queries. Returning them all is MUST strength, so it doesn't have the option of selectively removing some. Things are written so that the registrar need not be aware of *particular* feature tags to support them. Newly defined ones (such as being defined here) are recognized syntactically (via the leading "+").
> 
> If the registrar doesn't support "pref" it may or may not save and return Contact header field parameters. (It is neither required to do so nor forbidden from doing so.) In this case, I suppose it also *could* selectively prune (or add) parameters.
> 
> Also, the registrar has considerable latitude in its operation. As specified in 3261, it stores the registration bindings in an abstract location service. It is permissible for there to be other (unspecified) ways for the location service to be populated and manipulated. (A common case would be for the location service to be pre-populated with some default contacts.) Because of this, one could justify removing parameters from a binding by saying it might have been done by some external agent operating on the location service.
> 
> In general, callee capabilities (feature tags) and caller preference support by the proxy associated with the registrar are optional features, and you shouldn't be too surprised if they aren't supported.
> 
> In the case of the fax capability, I think you will probably want to include it in the registration *without* Require:pref. If it doesn't show up in the response to the REGISTER then you know it wasn't saved. If it did show up, you still don't know if callerprefs pertaining to it will be supported or not. What should you do? Nothing. You may get some non-fax calls and those will then fail. Maybe they will then be forked to another contact that succeeds, or not. That is not the concern of the fax device.
> 
> 	Thanks,
> 	Paul
> 
>> Thanks,
>> David
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Dec 7, 2012, at 6:22 AM, Kevin Fleming wrote:
> 
>> Paul already answered this question to Brian's satisfaction yesterday.
>>
>>
>> On Fri, Dec 7, 2012 at 4:01 AM, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> wrote:
>> Hi Paul,
>>
>> [I am adding Paul to this thread since he was a coauthor of RFC 3840]
>>
>> please, see below the exchange between Brian and Kevin regarding
>> draft-hanes-dispatch-fax-capability-06.txt.
>>
>> This was Brian's original comment:
>>
>>> Minor issue:
>>> ------------
>>>
>>>    ... A UA
>>>    preferring the reception of fax calls MUST include the "sip.fax"
>>>    media feature tag in the Contact header field of REGISTER messages.
>>>    To confirm the registration of this preference, a SIP [RFC3261]
>>>    Registrar MUST then include this tag in the Contact header field of
>>>    its 200 OK response.
>>>
>>> If the Registrar does not do this (e.g. because it hasn't been updated
>>> to support the new tag), what does the UA do when it receives the
>>> 200 OK response that doesn't include the tag?
>> Paul, can you share your views on this issue?
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>>
>>
> 
>