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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Dec 2012 10:38:39 +0000

Please see attached review.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Dec 2012 11:35:53 +0000

On 05/12/2012 11:01, Kevin Fleming wrote:
> The language in RFC 3840 doesn't appear to contemplate the situation you've
> proposed. In its world, registrars can either support prefs (and will
> accept "Require: pref") or they don't, and they don't have knowledge of
> which feature tags are registered with IANA and which are not. Of course,
> they *coud* attempt to validate the tags expressed by the UA, but I don't
> see an explicit way for the registrar to indicate that the UA included
> disallowed tags in its request.

Understood, but in that case I don't see what good the confirmation
of the tag from the registrar to the UA achieves - the UA is not going
to be able to do anything with it (except maybe log whether it was
received).

    Brian

---

From: Kevin Fleming <[email-masked]>
Date: Wed, 5 Dec 2012 06:01:44 -0500

---

From: Kevin Fleming <[email-masked]>
Date: Wed, 5 Dec 2012 09:12:03 -0500

I suppose it could choose to unregister and re-register in some other way
in order to achieve its goals of receiving FAX calls, if it was configured
with enough network information to do so.

Now that I think about it some more, is a registrar even allowed to return
a Contact header that differs from the one the UA supplied in its REGISTER
request? I suspect this is *not* allowed, and so if the registrar supports
Caller-Pref but the specific tag(s) in question fail some sort of
validation process, its only recourse would be to fail the REGISTER request
with a suitable error response.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Dec 2012 16:02:18 +0000

> with a suitable error response.

If that's the standard behaviour, it would of course answer my question.

   Brian

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 7 Dec 2012 11:01:43 +0200

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

---

From: Kevin Fleming <[email-masked]>
Date: Fri, 7 Dec 2012 06:22:34 -0500

Paul already answered this question to Brian's satisfaction yesterday.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Dec 2012 13:44:16 +0000

Kevin,

Actually it looks to me as if this error case is underspecified in
RFC 3840, which says:

   The REGISTER request MAY contain a Require header field with the
   value "pref" if the client wants to be sure that the registrar
   understands the extensions defined in this specification.  This means
   that the registrar will store the feature parameters, and make them
   available to elements accessing the location service within the
   domain.  In the absence of the Require header field, a registrar that
   does not understand this extension will simply ignore the Contact
   header field parameters.

However, I can't see any description of what happens in the failure
case (Require="pref" but the registrar does not understand). Maybe
it's supposed to be a 400 response, but I'm not sure that follows
inevitably from RFC 3840 and 3261.

That isn't a problem that the current draft can fix. When the draft
appears on the IESG agenda, I will update my review accordingly.

Thanks
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Dec 2012 13:47:21 +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:
> 
>> On Fri, Dec 7, 2012 at 4:01 AM, Gonzalo Camarillo <[email-masked]> wrote:
>> Hi Paul,
>>

---

From: David Hanes <[email-masked]>
Date: Fri, 7 Dec 2012 08:19:41 -0500

Hi Kevin,

Thanks,
David

I'll try.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Dec 2012 10:59:24 -0500

> inevitably from RFC 3840 and 3261.

RFC3261 has a specific error for this: 420 (Bad Extension).
This very standard behavior. There is no need for drafts that specify 
use of Require to spell this out.

	Thanks,
	Paul

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Dec 2012 16:42:29 +0000

> RFC3261 has a specific error for this: 420 (Bad Extension).

OK, excellent. Sorry to have gone on about this but SIP is a big
mouthful for a generalist reviewer.

Regards
   Brian Carpenter

On 07/12/2012 15:59, Paul Kyzivat wrote:
>>>>>>>> The language in RFC 3840 doesn't appear to contemplate the
>>>>>>>> situation
>>>>>>> you've
>>>>>>>> accept "Require: pref") or they don't, and they don't have
>>>>>>>> knowledge
>>>> of