Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-an sweralert-01)

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Nov 2005 09:46:46 -0500

I remain troubled about the semantics of Supports and Requires. I think 
they are considerably underspecified. In this case I think the evidence 
and precedent is in agreement with Dean, but there are exceptions. 
Exceptions are the bane if implementors, so I would encourage creating 
no more of them.

	Paul

Elwell, John wrote:
> Dean,
> 
> While I accept this would be reasonable behaviour for alert-info case, I
> still disagree with your statement that "SIP is actually very clear here --
> accepting the request with a Requires: option tag says only that you
> understand the extension, not that you are committing to doing what it says
> for this call."
> 
> In section 3 of RFC 3262 it states: "The UAS MUST send any non-100
> provisional response reliably if the initial request contained a Require
> header field with the option tag 100rel. If the UAS is unwilling to do so,
> it MUST reject the initial request with a 420 (Bad Extension) and include an
> Unsupported header field containing the option tag 100rel." So in this
> particular case you cannot accept the request but not honour the extension.
> 
> John
>  
> 
> 
>>-----Original Message-----
>>From: Dean Willis [mailto:[email-masked]] 
>>Sent: 28 October 2005 22:13
>>To: Elwell, John
>>Cc: Paul Kyzivat; [email-masked]; MARJOU Xavier RD-MAPS-LAN; 
>>[email-masked]
>>Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on 
>>draft-willis-sip-an sweralert-01)
>>
>>
>>On Oct 28, 2005, at 2:24 AM, Elwell, John wrote:
>>
>>
>>>Dean,
>>>
>>>
>>>
>>>>>The question then is: if the OPTION tag is there, should the
>>>>>request be rejected if the Alert-Info value isn't
>>>>>
>>>>
>>>>understood, or if
>>>>
>>>>
>>>>>it won't be honored?
>>>>>
>>>>>
>>>>
>>>>SIP is actually very clear here -- accepting the request with a
>>>>Requires: option tag says only that you understand the
>>>>extension, not
>>>>that you are committing to doing what it says for this call.
>>>>
>>>
>>>[JRE] This is already broken with 100rel.
>>>
>>
>>Not at all. You could always fail the transaction.  There's a  
>>difference between rejecting a request because you don't 
>>understand a  
>>specific extension and rejecting a request because your policy  
>>disallows acting on that extension for this specific request -- in  
>>one case you return a "bad extension" response, and in the other a  
>>"forbidden" with reason text explaining why it was forbidden ("403 I  
>>ain't doing preconditions with you, sucker!")
>>
>>It's like the difference between not supporting digest  
>>authentication, and not allowing a specific user to place a call.
>>
>>
>>I suppose it would be fair to say that it is up to the specific  
>>extension to say one of:
>>
>>1) If you accept a request but can't/won't honor the extension, the  
>>transaction proceeds with a potentially diminished or altered user  
>>experience.
>>2) If you accept a request but can't/wont honor the extension, then  
>>an error condition results.
>>
>>
>>This is one of the differentiators for P-class extensions: they have  
>>to be in class 1 above.  There are other differentiators, such as  
>>that P-headers are not allowed to have option tags, and they aren't  
>>required to be standards-track.
>>
>>
>>Alert-Info definitely falls into class 1. You might receive an Alert- 
>>Info with the semantic "distinctive ring associated with your 
>>primary  
>>line service", but have a user-interface that recognizes that the  
>>call is from your fiance's phone and instead plays Mendelsohn's  
>>"Wedding March". This doesn't break the protocol. So the same phone  
>>might receive an Alert-Info with the semantic "Emergency" and 
>>instead  
>>play your configured emergency tone. In both cases your phone  
>>understands the Alert-Info header and would accept the request even  
>>with a Require:.
>>
>>
>>--
>>Dean
>>
> 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 02 Nov 2005 13:28:28 -0500

> Exceptions are the bane if implementors, so I would encourage creating 

Perhaps I have not thought enough about this problem, but Supported and
Requires seem to be fairly simple to me --

Supported is used by a UA to advertise that it conforms to ("supports"
or "understands" in the vernacular) the particular RFC that defines the
listed option-tags.  Exactly what that conformance requires the UA to do
in various cases is defined by the RFC, of course.  Its presence in a
request does not place any constraint on the UAS that responds.

Requires is used in a request to modify the behavior of a UAS.  If the
UAS does not conform to the RFC in question, it MUST reject the request
with 420.  And so if it does not reject the request with 420, it MUST
perform whatever additional processing is required by the RFC.

Within this framework, what a UAC should do depends on its intentions as
to what should happen if the UAC does not understand the extension.  If
the UAC prefers the UAS to ignore the extension syntax elements (in the
default manner) so as to "complete the operation with diminished user
experience", it omits a Requires header.  If the UAC prefers that
instead the UAS reject the request, it includes a Requires header.
(These are, I think, Dean's two cases.  E.g., since all P-headers are to
be processed in the first manner, there is no option-tag for any of
them.)

So far, this doesn't seem to be controversial, and I think that all this
is specified or implied in one place or another.

If a UAS doesn't want to perform an extension when interacting with some
particular UAC, what should it do?  Ideally, the extension defines what
to do in this case.  Or it could reject the request based on
authorization; as far as I know, 403 is always allowed.  I suppose if
the request has a Requires, it can pretend it doesn't understand the
extension and return 420, but that is less useful (as 403 is closer to
reality), and semantically contradicts any mention of the extension in
other Supported headers.  Similarly, if the request doesn't have a
Requires, the UAS can pretend to not understand the extension and ignore
the use of the extension (though again contradicting any Supported that
it may have sent).

As an example, I see that in sections 20.4 and 20.9 of RFC 3261, a UA is
permitted to ignore the potentially hazardous headers Alert-Info and
Call-Info based on external factors.  Similarly, if there are aspects of
an extension that a UA might want to selectively allow or forbit, I'd
expect the RFC to make clear how a UA should deal with extension
requests that it does not want to honor for specific reasons.

Dale

---

From: Dean Willis <[email-masked]>
Date: Wed, 2 Nov 2005 14:29:06 -0600

> requests that it does not want to honor for specific reasons.

Yes, I believe this is exactly consistent with what I was trying to  
say. It's up to the extension to describe what should be done if you  
support an extension listed in a Require: header field but don't want  
(for whatever reason) to apply that extension to the specific request.

Otherwise said, what to do in this case is determined by the  
extension, not by the Require mechanism of RFC 3261. We have existing  
extensions that make different choices here already, and that seems  
to work ok.

But it would, I think, be useful to have a broader understanding of  
this concept so that the developers of new extensions can clearly  
document this decision in there new extensions.

I wonder if it's worth trying to tack something onto draft-ietf-sip- 
guidelines-09.txt?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Nov 2005 23:23:34 -0500

Response at end is really a new subject, hence a new subject line.

	Paul

> perform whatever additional processing is required by the RFC.

One issue is the one that has been discussed in this thread: do Supports 
and Requires just negotiate the *availability* of an option, or do they 
also, in one way or another, imply the *use* of an option.

For example, the GRUU spec calls for a UA that has obtained a gruu and 
is inserting it as a contact in some request to insert a Supported: 
gruu. Recipients of such a request are expected to interpret this as 
meaning that the contact in the request has the gruu property. So in 
that case the presence of the Supported header is being construed to 
mean that the sender *used* the option in a particular way.

My other problem with Supported, Required, Accept, Accept-Language, ... 
is that there is no clear definition of the scope over which this 
declaration applies. Some possible interpretations are:
1) just this message
2) this transaction
3) until the time of some action that the recipient is
    expected to take as a result of this message
4) for the remainder of this dialog
5) for the remainder of this dialog unless
   overridden later in the dialog
6) for all messages with this UA
7) for all messages with this UA unless
   overridden later

OPTIONS requests are supposed to specify these things. That seems to 
imply to imply the scope must be 6 or 7. But even if that is true, how 
would the recipient know uniquely when it is talking to the same UA? 
Without that it can't know when its prior knowledge applies.

Which scope is correct affects when a UA needs to insert this 
information into a request. If a UA doesn't include all info in every 
request is is making an implicit assumption that the recipient will 
retain this information until the UA sends it again. You can't get this 
right unless both parties agree on what this scope is.

AFAIK this has never been made clear. I'm pretty sure if we took a poll 
we would not see any concensus. (Maybe we ought to take that poll. IMO 
the only answers that make any sense are 3 & 5.)

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 03 Nov 2005 00:12:35 -0500

> mean that the sender *used* the option in a particular way.

Hmmm... I was going to reiterate my philosophy that Supported indicates
conformance to an RFC, rather than a specific feature of a message.
That would be boring, but I think it might be an entry-point to the core
of the problem.

Using Supported/Required only in regard to the UA-wide property of
whether it conforms to an RFC is straightforward, and it dodges the
issue of the scope over with the declaration applies -- it applies to
*all* messages, though of course, whether it implies anything about any
one particular message depends on the RFC.

>From this point of view, using "Supported: gruu" to indicate that the
Contact is a GRUU is fundamentally broken, as the UA either supports
GRUUs or not, regardless of whether it has obtained a GRUU that is
usable for this transaction.  I would then suggest that GRUU Contacts
should be indicated by a field-parameter of "gruu" or some such.
"Supported: gruu" is just the signal that the UA won't apply the gruu
field-parameter without it meaning "This Contact is a GRUU".  (I seem to
recall somebody suggested this a while back.)

> declaration applies. Some possible interpretations are:

So I would argue that if an extension could be applied to only part of a
UA's traffic, there would need to be a specifically defined facility in
the RFC to enable it.

> the only answers that make any sense are 3 & 5.)

It sounds like it would be useful to take that poll, if only to make it
clear how confused we are on the subject.

Dale

---

From: Dean Willis <[email-masked]>
Date: Thu, 3 Nov 2005 00:13:52 -0600

On Nov 2, 2005, at 11:12 PM, Dale R. Worley wrote:

> . . .

Ok, having looked at the GRUU draft again, I'd like to consider this  
a WGLC comment on GRUU, which I shall paraphrase as "What do you  
mean, Supported:?"

One could make the argument that a UA that supports GRUU would never,  
for any reason, populate the Contact in a transaction other than  
REGISTER (or the 200 OK thereto) with something that is not a GRUU,  
and that one can therefore assume that the presence of Supported:  
gruu in a message outside a REGISTER transaction means that the  
contact is a GRUU.  But if one were to make that argument, one would  
need to spell this out clearly.

One might also make the argument that the user of a contact need  
(outside a REGISTER transaction) never know whether that contact is a  
GRUU. Rather, if it works, it works. So the Supported: gruu means  
nothing outside a REGISTER or OPTIONS transaction, and very little in  
an OPTIONS transaction.

Or perhaps one might argue that I've built a castle of fallacious  
logic around the use of SIP option tags, and they really mean "If I  
put this option tag here, I'm either doing or requiring you do  
exactly what that option tag means". This then raises the possibility  
that policy might say we "do" an option for correspondent A but not  
for correspondent B, which means the "option tag constancy"  
characteristic of RFC 3261 is incorrectly worded (and I believe I  
argued for this model during 3261, but that was a while back).

--
Dean

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 03 Nov 2005 14:55:06 -0500

>From the looks of it, the I-D is close to what we've been discussing:

   Most other extensions of this type require that the server only
   insert the header field or parameter if it is sure the client
   understands it.  In this case, these extensions will need to make use
   of the Supported request header field mechanism.  This mechanism
   allows a server to determine if the client can understand some
   extension, so that it can apply the extension to the response.  By
   their nature, these extensions may not always be able to be applied
   to every response.

But I think that it would be good to see these conventions made more explicit.

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 3 Nov 2005 23:15:51 +0100

Dean, Dale,

I asked a question about this on this list (28/9), which Jonathan responded 
to on 20/10.

In summary, I asked if it wouldn't make more sense to use a parameter in the 
URI to indicate that it is a GRUU, instead of the Supported: gruu approach. 
My reasoning was that the other use cases for GRUUs ( e.g. as contact 
element in PIDF documents) would not have access to the Supported: header, 
so clients using the URI would not know if it was a GRUU or not.

Another (implicit) reason for my question was my impression that the way 
Supported: is used in this draft deviates from the way it is normally used. 
"Supported: timer" for example means - to me - that the UA understands the 
headers defined in the session timer RFC, Session-Expires, etc., and that it 
will behave in the way described there. Supported: gruu in a non-REGISTER / 
OPTIONS request means that the URI in the Contact header is a GRUU - hence 
my question "why not mark it in that header instead?"

Jonathan's anwer was:
"We have in fact discussed this a few times. As a general rule, its 
preferable to not include information in the URI itself which describes the 
properties of the resource to which the URI points"

I understood GRUU as a property of the URI, not the resource itself. I did 
not receive an answer to that, and don't know if it would change the outcome 
of this discussion.

As to the second part of my argument - that for other use cases clients 
won't know the URI is a GRUU - Jonathan's reply was: "In all of these cases, 
I don't think the recipient of the URI would do anything differently if it 
knew it was a gruu, as opposed to if it didnt. A GRUU is just a URI that has 
the property that URIs in Refer-To, contact and PIDF need to have in order 
to work right anyway. To date, we havent had a way to produce those URI 
reliably. Now we do."

So the question is: would the other side (or proxies on the path) behave 
differently when the Supported: gruu header is present?

The motivation given in the draft-06 states: "[...] since the remote target 
used by clients to date has typically not had the GRUU properties, 
implementations have adapted their behaviors (oftentimes in proprietary 
ways) to compensate.  To facilitate a transition away from these behaviors, 
it is necessary for a UA receiving the message to know whether the remote 
target is a GRUU or not." (section 5, non-normative)

In other words: "Supported: gruu" is a signal to implementations to ~not~ 
"adapt their behavior". So the assumption is that they would behave 
differently without the "Supported: gruu".

If this line of reasoning is followed, I think it should be applied 
consistently. By implication it should also be indicated if the Refer-To URI 
is a GRUU or not, under the assumption that implementations would otherwise 
"adapt their behavior". However, this creates an ambiguity when Supported: 
gruu is used to indicate that: What if a request is sent with both a Contact 
and a Refer-To header, and only one of the two is a GRUU?

IMO, the usage of Supported here is questionable (with the exception of the 
REGISTER and OPTIONS requests, for which it does makes sense)

Regards,

jeroen

----- Original Message ----- 
From: "Dean Willis" <[email-masked]>
To: "Dale R. Worley" <[email-masked]>
Cc: "Sip" <[email-masked]>
Sent: Thursday, November 03, 2005 7:13 AM
Subject: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea)

> Ok, having looked at the GRUU draft again, I'd like to consider this  a 
> WGLC comment on GRUU, which I shall paraphrase as "What do you  mean, 
> Supported:?"
>
> One could make the argument that a UA that supports GRUU would never,  for 
> any reason, populate the Contact in a transaction other than  REGISTER (or 
> the 200 OK thereto) with something that is not a GRUU,  and that one can 
> therefore assume that the presence of Supported:  gruu in a message 
> outside a REGISTER transaction means that the  contact is a GRUU.  But if 
> one were to make that argument, one would  need to spell this out clearly.
>
> One might also make the argument that the user of a contact need  (outside 
> a REGISTER transaction) never know whether that contact is a  GRUU. 
> Rather, if it works, it works. So the Supported: gruu means  nothing 
> outside a REGISTER or OPTIONS transaction, and very little in  an OPTIONS 
> transaction.
>
> Or perhaps one might argue that I've built a castle of fallacious  logic 
> around the use of SIP option tags, and they really mean "If I  put this 
> option tag here, I'm either doing or requiring you do  exactly what that 
> option tag means". This then raises the possibility  that policy might say 
> we "do" an option for correspondent A but not  for correspondent B, which 
> means the "option tag constancy"  characteristic of RFC 3261 is 
> incorrectly worded (and I believe I  argued for this model during 3261, 
> but that was a while back).
>
> --
> Dean
>
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 3 Nov 2005 18:40:47 -0600

On Nov 3, 2005, at 4:15 PM, Jeroen van Bemmel wrote:
>
> I understood GRUU as a property of the URI, not the resource  
> itself. I did not receive an answer to that, and don't know if it  
> would change the outcome of this discussion.
>

I agree with the assertion that GRUU is a property of the URI, not of  
the resource indicated by the URI.

However, I'm not certain that we need to know that the URI has the  
"GRUU properties". More on that later.

> As to the second part of my argument - that for other use cases  
> clients won't know the URI is a GRUU - Jonathan's reply was: "In  
> all of these cases, I don't think the recipient of the URI would do  
> anything differently if it knew it was a gruu, as opposed to if it  
> didnt. A GRUU is just a URI that has the property that URIs in  
> Refer-To, contact and PIDF need to have in order to work right  
> anyway. To date, we havent had a way to produce those URI reliably.  
> Now we do."
>
> So the question is: would the other side (or proxies on the path)  
> behave differently when the Supported: gruu header is present?
>
> The motivation given in the draft-06 states: "[...] since the  
> remote target used by clients to date has typically not had the  
> GRUU properties, implementations have adapted their behaviors  
> (oftentimes in proprietary ways) to compensate.  To facilitate a  
> transition away from these behaviors, it is necessary for a UA  
> receiving the message to know whether the remote target is a GRUU  
> or not." (section 5, non-normative)
>
> In other words: "Supported: gruu" is a signal to implementations to  
> ~not~ "adapt their behavior". So the assumption is that they would  
> behave differently without the "Supported: gruu".
>
> consistently. By implication it should also be indicated if the  
> Refer-To URI is a GRUU or not, under the assumption that  
> implementations would otherwise "adapt their behavior". However,  
> this creates an ambiguity when Supported: gruu is used to indicate  
> that: What if a request is sent with both a Contact and a Refer-To  
> header, and only one of the two is a GRUU?
>
> IMO, the usage of Supported here is questionable (with the  
> exception of the REGISTER and OPTIONS requests, for which it does  
> makes sense)

The open question is: would modes (other than registrars) really  
behave differently if they thought a URI to be a GRUU?

If not, then we have no need for the use of "Supported: gruu" as a  
hint, or to tag a URI as a GRUU syntactically.

If so, then we would appear to need a way, on a per-URI basis, to  
indicate that a URI isa GRUU.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Nov 2005 22:02:17 -0500

>>I wonder if it's worth trying to tack something onto draft-ietf-sip- 

I haven't looked at that in a long time. It raises some additional 
questions in my mind. For instance:

    In order to achieve backwards compatibility for extensions that
    define new methods, the Allow header field is used.  There are two
    types of new methods - those that are used for established dialogs
    (initiated by INVITE, for example), and those that are sent as the
    initial request to a UA.  Since INVITE and its response both SHOULD
    contain an Allow header field, a UA can readily determine whether the
    new method can be supported within the dialog.  For example, once an
    INVITE dialog is established, a user agent could determine if the
    REFER method [12] is supported if it is present in an Allow header.
    If it wasn't, the "transfer" button on the UI could be "greyed out"
    once the call is established.

This implies that the scope of Allow is, or at least encompasses, the 
dialog. Similarly:

    When a body must be understood to properly process a request or
    response, it is preferred that the sending entity know ahead of time
    whether the new body is understood by the recipient.  For requests
    that establish a dialog, inclusion of Accept in the request and its
    success responses is RECOMMENDED.  This will allow both parties to
    determine what body types are supported by their peers.  Subsequent
    messaging between the peers would then only include body types that
    were indicated as being understood.

implies that the scope of Accept is a dialog. Perhaps I read too much 
into this language. But the emphasis that dialog establishing requests 
and their responses should include these things also implies that other 
requests and responses need not. But at best this is an incomplete set 
of rules.

> But I think that it would be good to see these conventions made more explicit.

I agree.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 06 Nov 2005 13:37:03 -0500

inline.

> (for whatever reason) to apply that extension to the specific request.

I agree with this, that is the intent of Supported/Require.

I think the confusion caused by 100rel is that the spec tells you that 
if you don't want to honor the extension, you "pretend" that you don't 
implement it, and thus reject with a 420. This, then, begs the question 
that Paul has asked about scope of Allow, Accept, etc.

I'll post separately on that in a moment...

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 06 Nov 2005 13:42:33 -0500

inline.

Dean Willis wrote:

> REGISTER (or the 200 OK thereto) with something that is not a GRUU,  and 
> that one can therefore assume that the presence of Supported:  gruu in a 
> message outside a REGISTER transaction means that the  contact is a 
> GRUU.  But if one were to make that argument, one would  need to spell 
> this out clearly.

That is the intent.

The idea is this - the GRUU spec basically says, at MUST strength, that 
you have to use your GRUU in the contact of dialog forming requests and 
responses. Supported:gruu implies ONLY that the UA sending the request 
supports the gruu spec. As a consequence, since the gruu spec implies 
that a compliant implementation also place a GRUU into the contact, the 
presence of Supported:gruu ALSO implies that the request contains a GRUU 
in the contact.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 06 Nov 2005 13:56:48 -0500

inline.

> Without that it can't know when its prior knowledge applies.

I agree that this has really become a mess. The idea when 3261 was being 
written IIRC is that its really (6), but this doesn't work awfully well 
since, as you say, you don't know if you're talking to the same UA when 
you send a request to a particular URI.

Most of these headers are inherited from HTTP, where they had two 
different meanings. Some, like Allow, were really properties of the 
resource itself. Others, like Accept, were useful for the transaction 
only to indicate what can come in the response. SIP "borrowed" these, 
but the different nature of SIP resources compared to HTTP ones has 
introduced a lot of confusion here.

The difficulty as Paul has pointed out is that support for various 
extensions, headers, and methods is ultimately a property of a 
particular instance of software. However, a typical SIP URI, an in 
particular an AOR like sip:[email-masked], represents a user that can 
be reached at possibly many pieces of software. To make matters messier, 
software can also be upgraded over time, so even if a UA routed to a 
particular instance, these properties arent truly static.

Things get a little cleaner if you assume that an instance ID (in the 
gruu sense) changes for a UA when its firmware or software changes. In 
such a case, there could be a static relationship between the Allow, 
Accept, etc. values and an instnace ID, and you could cache that 
relationship. Using those values to guess how to construct a request 
would then only be useful when sending a reuqest to a known instance. 
That happens for mid-dialog requests, but also for requests targeted to 
a gruu.

One question, though, is whether it is allowed to indicate different 
capabilities for a UA instance depending who is asking. We have 
generally allowed that for other things, and allowing it here (as 100rel 
basically does) breaks the model that you could cache these properties 
as associated with an instance ID, UNLESS you basically changed instance 
IDs if you change values of Allow, Accept, etc.

We should definitely try and figure out what the scope really is and put 
that somewhere in a document, or at least into the bugzilla instance.

Thanks,
Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Mon, 7 Nov 2005 16:24:26 -0600

On Nov 6, 2005, at 12:42 PM, Jonathan Rosenberg wrote:

>
> The idea is this - the GRUU spec basically says, at MUST strength,  
> that you have to use your GRUU in the contact of dialog forming  
> requests and responses. Supported:gruu implies ONLY that the UA  
> sending the request supports the gruu spec. As a consequence, since  
> the gruu spec implies that a compliant implementation also place a  
> GRUU into the contact, the presence of Supported:gruu ALSO implies  
> that the request contains a GRUU in the contact.
>

I think I'm OK with this, but the gruu text should make this more clear.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Nov 2005 23:58:13 -0500

> presence of Supported:gruu ALSO implies that the request contains a GRUU 

And in the Refer-To of REFER? And in *all* the Contacts of a 3xx? And in 
???.

What happens when there are multiple addresses in the message and only 
some of them are known to have the GRUU property?

For instance, suppose I'm sending a REFER, and I know the Refer-To is a 
gruu, but I wasn't able to get a gruu for the Contact in my own REFER? 
Do I put a Supported: gruu in the REFER request?

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Nov 2005 00:18:47 -0500

Jonathan Rosenberg wrote:
> inline.
> 
> Paul Kyzivat wrote:
> 
> 
>> My other problem with Supported, Required, Accept, Accept-Language, 
>> ... is that there is no clear definition of the scope over which this 

In some cases, whether something is supported depends on context - the 
same UA may support it in one context, but not another. The Accept 
header is a good case of this: I might Accept SDP in INVITE, UPDATE, 
PRACK, and their responses, but not in other places. Or I might support 
multipart/alternative in MESSAGE but not elsewhere.

> That happens for mid-dialog requests, but also for requests targeted to 

That could help.

> IDs if you change values of Allow, Accept, etc.

I didn't follow that. If I am disclosing capabilities, and do so 
differently when talking to X than Y, then I see no problem with X and Y 
caching those results as long as I am consistent in what I report to 
each of them.

> that somewhere in a document, or at least into the bugzilla instance.

Yeah, as things stand nobody knows when they should/needn't insert these 
headers, and nobody knows how to remember them. This doesn't bode well 
for interoperability.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Nov 2005 12:25:49 -0500

inline.

Paul Kyzivat wrote:

>> be reached at possibly many pieces of software. To make matters 
>> messier, software can also be upgraded over time, so even if a UA 
>> routed to a particular instance, these properties arent truly static.
> 
> 

In principal this is a problem. Is it true in practice? If a particular 
extension can (according to the spec), be used with INVITE and UPDATE, 
and an implementation supports the spec, are there implementations that 
would only use it for INVITE and not UPDATE?

My suspicion is that this is actually rare, and furthermore, that when 
it does happen, you really need to view it differently. The UA does 
SUPPORT the extension, it just elects not to utilize it.

>> That happens for mid-dialog requests, but also for requests targeted 
>> to a gruu.
> 
> 
> That could help.
> 
>> generally allowed that for other things, and allowing it here (as 
>> 100rel basically does) breaks the model that you could cache these 
>> properties as associated with an instance ID, UNLESS you basically 
>> changed instance IDs if you change values of Allow, Accept, etc.
> 
> 

Fair point. The bigger problem is if you change what you said to a 
particular caller, without changing instance ID.

> 
>> We should definitely try and figure out what the scope really is and 
>> put that somewhere in a document, or at least into the bugzilla instance.
> 
> 

In principal I suppose. I'm curious if anyone has seen interop problems 
in the wild as a consequence of this...

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Nov 2005 12:59:14 -0500

More inline.

	Paul

Jonathan Rosenberg wrote:
>>> particular an AOR like sip:[email-masked], represents a user that 
>>> can be reached at possibly many pieces of software. To make matters 
>> PRACK, and their responses, but not in other places. Or I might 
>> support multipart/alternative in MESSAGE but not elsewhere.
> 

I suspect this is not a problem with options. But I think it is very 
likely a problem with content types.

Consider a softphone that supports INVITE and MESSAGE. If done on a 
UA-wide basis, I think it must say

    Accept: application/sdp, text/plain

But what is it going to do if I send it a MESSAGE containing an SDP 
body? It probably can't accept it. If it wants to refuse it, what error 
can it return? I think it must return 415:

    21.4.13 415 Unsupported Media Type

    The server is refusing to service the request because the message
    body of the request is in a format not supported by the server for
                                                                   ^^^
    the requested method.  The server MUST return a list of acceptable
    ^^^^^^^^^^^^^^^^^^^^
    formats using the Accept, Accept-Encoding, or Accept-Language header
    field, depending on the specific problem with the content.  UAC
    processing of this response is described in Section 8.1.3.5.

In that response it would have to include a new Accept header:

    Accept: text/plain

to indicate what is valid for the MESSAGE. But this too is not clearly 
scoped to apply to the particular message.

>>> gruu sense) changes for a UA when its firmware or software changes. 
>>> In such a case, there could be a static relationship between the 
>>> Allow, Accept, etc. values and an instnace ID, and you could cache 
>>> that relationship. Using those values to guess how to construct a 
>>> request would then only be useful when sending a reuqest to a known 
>>> instance. That happens for mid-dialog requests, but also for requests 
>>> targeted to a gruu.
>>
>> That could help.
>>
>> differently when talking to X than Y, then I see no problem with X and 
>> Y caching those results as long as I am consistent in what I report to 
>> each of them.
> 
>> Yeah, as things stand nobody knows when they should/needn't insert 
>> these headers, and nobody knows how to remember them. This doesn't 
>> bode well for interoperability.
> 

Yes, I too am curious. Maybe it doesn't matter because nobody conditions 
their behavior on what they receive this way.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Nov 2005 14:12:33 -0500

inline.

Paul Kyzivat wrote:

>>> One could make the argument that a UA that supports GRUU would 
>>> never,  for any reason, populate the Contact in a transaction other 
>>> than  REGISTER (or the 200 OK thereto) with something that is not a 
>>> GRUU,  and that one can therefore assume that the presence of 
>>> Supported:  gruu in a message outside a REGISTER transaction means 
>>> that the  contact is a GRUU.  But if one were to make that argument, 
>>> one would  need to spell this out clearly.
>>
>>
>> That is the intent.
>>

I don't follow you here. Refer-To is different; this doesn't usually 
contain MY URI, its someone elses that is pulled from somewhere 
(Contact). Whether you'd place your own gruu into a redirect, I don't 
know of a user case for that.

> some of them are known to have the GRUU property?

We're only talking about contact.

> Do I put a Supported: gruu in the REFER request?

Supported: gruu means that the endpoints supports GRUU, and that as a 
consequence, the Contact in dialog forming requests (like REFER) will 
contain a gruu for the UAC. Supported:gruu says NOTHIGN about the 
contents of Refer-To since the GRUU spec isn't about that.

-Jonathan R.