Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 May 2014 15:16:55 +0000

Hi Paul,

>>> Then, the description of the parameter says the uri with the parameter is the *end* of a traffic leg with that name. It says nothing about which node or URI *starts* each leg.
>>
>> The each value description, the text says between which 3GPP nodes the traffic leg spans. There is no need to indicate the *start* in the signaling.
>
> There is no need because it is implicit?
> Or because it is not needed for the uses you have in mind?

Correct. The purpose of the parameter is to inform entities about the traffic leg.

But, for 3GPP, the value definition implicitly DO provide information between what types of entities the traffic leg span.

>>> If B2BUAs (especially SBCs) are involved, is it important whether the iotl parameters are preserved e2e?
>>
>> The iotl parameter only needs to be preserved until it is "consumed" at the end of the traffic leg.
>
> That seems to open up another discussion. It is a continuation of the
> question I had above who uses the iotl parameter values, and for what.
>
> When you say that the parameter identifies the end of a leg, and is
> consumed at the end of the leg, that implies to me that this serves as a
> request that the node identified by the URI perform some action implied
> by the iotl value.

The node identified by the URI, AND intermediaries on the traffic leg, that perform actions based on the value.

This is NOT a parameter used to request nodes to perform specific actions, and whatever entities do what the information is outside the scope of the document.

The purpose of the parameter is to inform nodes about the traffic leg, and whatever (if any) actions taken are based on local/operator policy.

> If that is what this is about, then it should be spelled out clearly.

The Introduction contains some text, including the following paragraph:

"The traffic leg information can be used by intermediary entities to
make policy decisions, related to e.g. media anchoring, signalling
policy, insertion of media functions (e.g. transcoder) and charging."

But, if more text is needed, we can of course add that.

However, I don't think we should copy/paste the 3GPP specification into the draft. The 3GPP specification is available for anyone who wants detailed information on what actions nodes take in certain scenarios etc.

Regards,

Christer

---

From: Michael Hammer <[email-masked]>
Date: Thu, 1 May 2014 15:20:32 +0000

Will the 3GPP spec change if the manifestation of this parameter changes?

________________________________
Michael Hammer
Principal Engineer
[email-masked]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Christer
Holmberg
Sent: Thursday, May 01, 2014 11:17 AM
To: Paul Kyzivat; [email-masked]
Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00

Hi Paul,

>>> Then, the description of the parameter says the uri with the parameter
is the *end* of a traffic leg with that name. It says nothing about which
node or URI *starts* each leg.
>>
>> The each value description, the text says between which 3GPP nodes the
traffic leg spans. There is no need to indicate the *start* in the
signaling.
> Or because it is not needed for the uses you have in mind?

Correct. The purpose of the parameter is to inform entities about the
traffic leg.

But, for 3GPP, the value definition implicitly DO provide information
between what types of entities the traffic leg span.

> consumed at the end of the leg, that implies to me that this serves as 
> a request that the node identified by the URI perform some action 
> implied by the iotl value.

The node identified by the URI, AND intermediaries on the traffic leg, that
perform actions based on the value.

This is NOT a parameter used to request nodes to perform specific actions,
and whatever entities do what the information is outside the scope of the
document.

The purpose of the parameter is to inform nodes about the traffic leg, and
whatever (if any) actions taken are based on local/operator policy.

"The traffic leg information can be used by intermediary entities to make
policy decisions, related to e.g. media anchoring, signalling policy,
insertion of media functions (e.g. transcoder) and charging."

However, I don't think we should copy/paste the 3GPP specification into the
draft. The 3GPP specification is available for anyone who wants detailed
information on what actions nodes take in certain scenarios etc.

Regards,

Christer
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 May 2014 15:21:10 +0000

Hi,

>As far as I can tell, the draft refers to "signaling path", but it
>does not distinguish whether the signaling path is the routing of a
>single dialog, or whether it is broken into multiple dialogs by
>B2BUAs.  I don't think this changes the proposal technologically, but
>it should probably be stated explicitly somewhere.  It *is* a
>requirement of the solution.

Sure, we can add text about that.

>It seems that the intention is that at any point, a progressing
>dialog-establishing or out-of-dialog request is labeled regarding
>which call leg it is within by the iotl parameter of the URI currently
>used for routing (the topmost Route or the request URI).  This is a
>bit incorrect categorically, because:
>
>1. it's not a property of the destination, its a property of the
>   dialog, or part of the dialog

It depends on the traffic leg. Some traffic legs end at the destination.

>2. overlooking that, it's not really a property of the URI, its a
>   modifier of how the URI is *used*

I am not really sure what you mean by that. We are not suggesting any changes to how URIs are used. The parameter simply provides additional information to the consumer of the URI.

>(1) suggests that there should be a separate header to label the
>request.  But that might be even more complex to define in order to be
>able to have a single dialog contain several call legs.
>
>(2) suggests that the iotl data should not be a URI parameter, but
>rather a header parameter.  The Route header has header parameters,
>but the request-URI doesn't; I suppose the analogous item is the To
>header, which does have header parameters.

The parameter can, based on the use-case, be used both in the SIP URI of a Route header, or in the Request-URI.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 May 2014 15:26:45 +0000

Hi,

>Will the 3GPP spec change if the manifestation of this parameter changes?

This is needed for the current 3GPP release, and there are requests for this to be implemented, so therefor I hope we can agree on the basics relatively fast.

We can then always make sure we have enough text, clarifications etc in the draft.

Regards,

Christer

-----Original Message-----

Hi Paul,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 May 2014 12:14:50 -0400

> The purpose of the parameter is to inform nodes about the traffic leg, and whatever (if any) actions taken are based on local/operator policy.

(I'm still trying to understand.)

I *think* you are defining a new state machine for requests - that the 
request transitions among states as it is routed from the source to the 
destination. the iotl parameter identifies the current value of that 
state, and that when the request reaches the server responsible for the 
URI the parameter is attached to then the request leaves that state, and 
will enter some new state defined by the state machine.

And then servers along the path can observe the current state value and 
adjust their behavior.

Is that about right?

But if I have this right, why does this need to be attached to a URI? 
Why is it necessary to identify the end node for this state? Surely the 
ending node knows that it does that.

> But, if more text is needed, we can of course add that.

Explanation of the abstract model of how this is intended to work is 
what I have in mind. Like the state model I mention above.

> However, I don't think we should copy/paste the 3GPP specification into the draft. The 3GPP specification is available for anyone who wants detailed information on what actions nodes take in certai…

No. If that is required then the scope of this draft should be narrowed 
to just 3gpp.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 May 2014 21:14:09 +0000

Hi,

> And then servers along the path can observe the current state value and

I don't think so :)

This is not so much about the request it self. It is simply about providing information to other nodes about the traffic leg type on which the request is sent, and to indicate the end of the traffic leg.

So, I don't see why this would be associated with a state machine for requests.

> But if I have this right, why does this need to be attached to a URI?

Because the end of the traffic leg is associated with the URI.

> ending node knows that it does that.

A node may not act as ending node for all types of traffic leg types. And, if a node can act as ending node for different traffic leg types, it needs to with which a given request is associated with.

> No. If that is required then the scope of this draft should be narrowed to just 3gpp.

I have no problem with that.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 May 2014 18:25:38 -0400

>> And then servers along the path can observe the current state value and

Then I'm *still* trying to understand!!!

When I look at Figure 1 I see evidence for a state machine. Certain 
sequences of values from section 4.2 are possible, and others are not.

> This is not so much about the request it self. It is simply about providing information to other nodes about the traffic leg type on which the request is sent, and to indicate the end of the traffi…

How do other nodes determine the traffic leg type?

What I can infer from the draft is:

1) if the parameter is on the R-URI, then that determines the current 
traffic leg type.

2) else, if one or more URIs in the Route header field have this 
parameter, then the first one that does *might* determine the traffic 
leg type. (Not certain until that URI moves from the Route header to the 
R-URI. Until then a parameter with another value *might* be inserted so 
as to preempt this one.)

3) Presence in Path or Service-Route doesn't determine the traffic leg type.

It is (2) that raises many questions. Can that situation ever 
legitimately happen? If so, isn't that a problem for any node that makes 
a decision based on a value that is later preempted?

Or maybe only the R-URI is to be used to make decisions?

> A node may not act as ending node for all types of traffic leg types. And, if a node can act as ending node for different traffic leg types, it needs to with which a given request is associated wit…

I find that very confusing. I presume you mean something like an S-CSCF? 
That it may be visited many times by the same request, performing 
different roles each time. AFAIK, even in that case at each visit the 
server has information that allows it to determine what it is doing. But 
I don't have a full understanding of that.

> I have no problem with that.

That is a decision for you to make. If you want to narrow the scope to 
just 3gpp then the draft will follow a different track - not dispatch.

If it is to be viewed as applicable to the internet as a whole, then it 
needs to specify the semantics well enough that others can decide *if* 
it would be generally useful, and if so, then *how* it should be used.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 May 2014 07:41:26 +0000

Hi,

> 1) if the parameter is on the R-URI, then that determines the current traffic leg type.
>
> 2) else, if one or more URIs in the Route header field have this parameter, then the first one 
> that does *might* determine the traffic leg type. (Not certain until that URI moves from the Route header 
> to the R-URI. Until then a parameter with another value *might* be inserted so as to preempt this one.)

In the 3GPP scenarios, there will always only be at most one iotl parameter in either the R-URI or in one of the Route header fields, and whenever such parameter is present the request is traversing the indicated traffic leg type.

So, if we limit the draft to 3GPP, that should not be an issue.

And, we do intend to provide more call flow information etc in the next version, which hopefully makes things more clear.

> 3) Presence in Path or Service-Route doesn't determine the traffic leg type.

Correct. 

During registration, when a node inserts a Path, if the node knows that it will act as an endpoint for requests traversing the registration path, it can insert the parameter in its URI. But, the URI will have no meaning until it is actually used in a request (e.g. an initial INVITE) sent on the registration path.

> It is (2) that raises many questions. Can that situation ever legitimately happen? If so, isn't that a problem for any node that makes a decision based on a value that is later preempted?
>

See above.

>> A node may not act as ending node for all types of traffic leg types. And, if a node can act as ending node 
>> for different traffic leg types, it needs to with which a given request is associated with.
>
> That it may be visited many times by the same request, performing different roles each 
> time. AFAIK, even in that case at each visit the server has information that allows it to determine 
> what it is doing. But I don't have a full understanding of that.

It is not so much about a given request visiting the same node multiple times.

It is more about a node receiving multiple different requests (for different calls etc), and each time the traffic leg type may be different. A typical example are IBCFs (3GPP network border entities), which may be parts of different traffic leg types.

> That is a decision for you to make. If you want to narrow the scope to just 3gpp then the draft will follow a different track - not dispatch.

So, what is the right path, then? Should 3GPP define the parameter themselves?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 May 2014 15:05:36 -0400

> So, if we limit the draft to 3GPP, that should not be an issue.

Well, if this is to be more generally applicable, then ISTM there needs 
to be a general mechanism to determine what leg type is in effect. The 
easy way seems to be to identify this as a restriction - only one 
instance of the iotl parameter across the Route header and the R-URI.

> So, what is the right path, then? Should 3GPP define the parameter themselves?

New SIP/SIPS URI Parameters require Standards Action, which means it 
must come from a WG or be AD sponsored. AD sponsored might be better for 
something specific to 3gpp, if an AD is willing to do so. Else I guess 
it must go through a WG such as this one.

But first you might make an effort to "sell" this mechanism as generally 
useful. (So far I'm having trouble seeing that.)

Or you might want to seek some other mechanism where the iana 
registration is less restrictive.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 2 May 2014 17:16:16 -0400

> From: Christer Holmberg <[email-masked]>

> I am not really sure what you mean by that. We are not suggesting
> any changes to how URIs are used. The parameter simply provides
> additional information to the consumer of the URI.

What you said is actually my point -- the iotl value isn't *part* of
the URI, it's information to be used *in addition* to the URI.  And
URI parameters are *part* of the URI, among other things, they should
be opaque except to the SIP entity that they name.  Since iotl is
*additional* to the URI, it really ought to be in a header parameter,
not a URI parameter.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 3 May 2014 13:51:12 +0000

Hi,

> instance of the iotl parameter across the Route header and the R-URI.

I agree. And, we can say that the starting node of a traffic leg MUST verify this.

...

> useful. (So far I'm having trouble seeing that.)

If people from the non-3GPP community doesn't see a need in this I am not going to try to convince them :)

> Or you might want to seek some other mechanism where the iana registration is less restrictive.

There were discussions in 3GPP to e.g. use feature capability indicators, but it was realized that the semantics don't fit. The outcome was that a URI parameter is the best solution, and I personally also support that view.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 3 May 2014 13:59:32 +0000

Hi,

> *additional* to the URI, it really ought to be in a header parameter,

URI parameters can be used to provide additional information associated with an URI.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 4 May 2014 21:38:18 -0400

I think that the proper way to deal with "iotl" is not as a proposed
standard, but as an informational RFC.  For a long list of reasons, I
think that the benefit from trying to handle this as a standardization
question will be small relative to the amount of work needed.  But it
would be useful to document the solution the IMS people have
implemented to their problem.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 May 2014 06:37:30 +0000

Hi,

Based on the comments so far, some more text would be needed, but in general I think most of the work is already done - especially if we scope the solution to 3GPP.

But, having said that, I don't have any strong feelings how it's documented. Standards track, informational, documented in 3GPP - you tell me - I do :)

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: 5. toukokuuta 2014 4:38
To: [email-masked]
Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00

I think that the proper way to deal with "iotl" is not as a proposed standard, but as an informational RFC.  For a long list of reasons, I think that the benefit from trying to handle this as a standardization question will be small relative to the amount of work needed.  But it would be useful to document the solution the IMS people have implemented to their problem.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 5 May 2014 09:44:59 -0400

> From: "DOLLY, MARTIN C" <[email-masked]>
> 
> > On May 4, 2014, at 9:38 PM, "Dale R. Worley" <[email-masked]> wrote:
> > For a long list of reasons, I
> > question will be small relative to the amount of work needed.

> And those reasons are?

It's not clear what the general problem is for which the 3GPP solution
is a specific solution.  Thus, clarifying the general problem and its
requirements would take considerable work.

Nobody other than 3GPP has expressed that they have a problem of this
nature.  Thus, getting people to work on the problem may be difficult.

There don't seem to be any scenarios where interoperation is needed,
either between supporting and non-supporting SIP implementations or
between supporting SIP implementations that use different definitions
of the "call leg" structure.  If all usage is within "walled gardens"
where technical uniformity can be enforced administratively, there is
no practical need for a global standard.

Doubts have been expressed in the IETF that the current implementation
is the best solution from an architectural point of view.
Nonetheless, 3GPP is unlikely to obtain significant additional benefit
if the IETF finds a "better" solution, and it seems 3GPP would be
unlikely to change their implementation if the IETF were to decree a
"better" standard.

Taking all of this together, it seems that the IETF is unlikely to
complete a proper standards effort for this problem and that there
would be little benefit obtained from developing a proper standard.
The IETF has a longstanding policy against declaring that something is
a standard just because it has been implemented, so we can't declare
this a standard simply because 3GPP is using it.  OTOH, it would be
useful to document that this is how 3GPP solves this problem.

The only difficulty I see is that the IANA registry "SIP/SIPS URI
Parameters" (
http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-11
) is marked "Registration Procedure(s): Standards Action", and we'd
really like to have a pointer from the registry to the informational
RFC.  I suppose we could just ask the IESG to make the update.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 May 2014 10:00:50 -0400

> RFC.  I suppose we could just ask the IESG to make the update.

I'm not sure I follow what you are suggesting.

As you note, the registration procedure requires "Standards Action" and 
that requires a "Standards Track" RFC. IIUC an Informational RFC isn't 
Standards Track. Is that the point you are making? Are you suggesting 
that the IESG could override this?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 May 2014 17:20:37 +0000

Hi,

>>> For a long list of reasons, I think that the benefit from trying to handle this as a 
>>> standardization question will be small relative to the amount of work needed.
>>
>> And those reasons are?
>
> It's not clear what the general problem is for which the 3GPP solution is a specific solution.  Thus, 
> clarifying the general problem and its requirements would take considerable work.

As far as I know, based on the agreement between 3GPP and IETF, there doesn't have to be a general problem. 

...

> Doubts have been expressed in the IETF that the current implementation is the best solution from
> an architectural point of view.

I am not sure what you mean by that.

You have claimed that a URI parameter has to "be part of" a URI. I disagree with that. Take a look at the existing URI parameters. For example, do you consider the commonly used "lr" parameter being "part of" a URI? In my opinion, it provides additional information about the URI - in the same way as "iotl" does.

(Also note that the URI parameters (the only exception being the user parameter) are not part of the canonical representation of the URI).

> Nonetheless, 3GPP is unlikely to obtain significant additional benefit if the IETF finds a "better" 
> solution, and it seems 3GPP would be unlikely to change their implementation if the IETF were to 
> decree a "better" standard.
>
> Taking all of this together, it seems that the IETF is unlikely to complete a proper standards effort 
> for this problem and that there would be little benefit obtained from developing a proper 
> standard.
> The IETF has a longstanding policy against declaring that something is a standard just because it has
> been implemented, so we can't declare this a standard simply because 3GPP is using it.  OTOH, it 
> would be useful to document that this is how 3GPP solves this problem.

I don't think I have claimed that this has already been implemented. I HAVE said, however, that 3GPP needs to for the current release (Rel-12), so there IS a time aspect.

If the suggested solution doesn't work, or there is another reason it can't be used, of course we have to come up with something else. 

But, I don't understand why the first task should be to look for another solution, just for the sake of looking for another solution... 

> The only difficulty I see is that the IANA registry "SIP/SIPS URI Parameters" (
> ) is marked "Registration Procedure(s): Standards Action", and we'd really like to have a pointer 
> from the registry to the informational RFC.  I suppose we could just ask the IESG to make the 
> update.

Personally, I don't have any strong opinion regarding that. I just want to do the work :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 May 2014 17:24:32 +0000

Hi,

> As you note, the registration procedure requires "Standards Action" and that requires a "Standards > Track" RFC. IIUC an Informational RFC isn't Standards Track. Is that the point you are making? Are 
> you suggesting that the IESG could override this?

Or, is the suggestion to document the solution in an Informational RFC, but to NOT register the parameter?

Regards,

Christer

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 5 May 2014 17:31:27 +0000

Dale,

Thank you for responding to the list for a "private" question I sent you.

Regards,

Martin

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: Monday, May 05, 2014 9:45 AM
To: [email-masked]
Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 5 May 2014 17:28:21 -0400

> From: Paul Kyzivat <[email-masked]>
> 
> Standards Track. Is that the point you are making?

Yes.  If we're going to document iotl at all, it should go into the
table of URI parameters.  But strictly speaking, it seems that an
informational RFC can't add an entry to this registry.

> Are you suggesting that the IESG could override this?

I don't know for certain, but it seems to me to be likely that it can,
and that would be a way around the apparent problem.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 May 2014 06:30:49 +0000

Perhaps the chairs and/or ADs could give some guidance?

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: 6. toukokuuta 2014 0:28
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00

> As you note, the registration procedure requires "Standards Action" 
> and that requires a "Standards Track" RFC. IIUC an Informational RFC 
> isn't Standards Track. Is that the point you are making?

Yes.  If we're going to document iotl at all, it should go into the table of URI parameters.  But strictly speaking, it seems that an informational RFC can't add an entry to this registry.

> Are you suggesting that the IESG could override this?

I don't know for certain, but it seems to me to be likely that it can, and that would be a way around the apparent problem.

Dale

---

From: Mary Barnes <[email-masked]>
Date: Tue, 6 May 2014 09:30:54 -0500

I thinks it's a bad idea to bend the rule and allow registration of SIP URI
parameters in an informational document.   I haven't considered the problem
you're trying to solve in detail, but ISTM that Dale had a good suggestion
to use header field parameters.  And, if it's unique to 3GPP, you can
define a P-header field.  Is there a reason why this would not work?

Mary

On Tue, May 6, 2014 at 1:30 AM, Christer Holmberg <
[email-masked]> wrote:

> Yes.  If we're going to document iotl at all, it should go into the table
> of URI parameters.  But strictly speaking, it seems that an informational
> RFC can't add an entry to this registry.
>
> I don't know for certain, but it seems to me to be likely that it can, and
> that would be a way around the apparent problem.
>
> Dale
>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 6 May 2014 11:17:47 -0400

> From: Mary Barnes <[email-masked]>

> ... use header field parameters ...

Hmmm, I wouldn't have expected it, but the registration criterion for
"Header Field Parameters and Parameter Values" (
http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-12
) is "Published RFC (A standards-track RFC is NOT required)".

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 6 May 2014 11:32:43 -0400

> RFC, but to NOT register the parameter?

I believe that there is significant benefit to having the parameter
recorded in the registry, due to the sheer volume of 3GPP usage if
nothing else.  So whatever path we take should lead to a proper
registration.

This is one of the conveniences of P- headers, in that I don't see
them as output of IETF work, but that the IETF simply catalogs work
that was done by 3GPP.

> You have claimed that a URI parameter has to "be part of" a URI. I
> disagree with that. Take a look at the existing URI parameters. For
> example, do you consider the commonly used "lr" parameter being
> "part of" a URI? In my opinion, it provides additional information
> about the URI - in the same way as "iotl" does.

I believe that the "lr" URI parameter is an architectural error, and
should have been a header field parameter.

> (Also note that the URI parameters (the only exception being the
> user parameter) are not part of the canonical representation of the
> URI).

I was not aware that there is a canonical form of SIP URIs, but one is
described in 3261:

      10.3 Processing REGISTER Requests

      5. The registrar extracts the address-of-record from the To header
         field of the request.  If the address-of-record is not valid
         for the domain in the Request-URI, the registrar MUST send a
         404 (Not Found) response and skip the remaining steps.  The URI
         MUST then be converted to a canonical form.  To do that, all
         URI parameters MUST be removed (including the user-param), and
         any escaped characters MUST be converted to their unescaped
         form.  The result serves as an index into the list of bindings.

The 'user' parameter is to be removed as well.  As far as I've managed
to track it, the only prescribed use of a canonical form is for
registration lookups.

On the other hand, URI parameters are included in URI comparison
(19.1.4).  And as far as I can tell, those rules do not lead to a
canonical form, because the defined URI equality is not an equivalence
relation.  (That is, A can compare equal to B and also compare equal
to C, but yet B does not compare equal to C.)

> I don't think I have claimed that this has already been
> implemented. I HAVE said, however, that 3GPP needs to for the
> current release (Rel-12), so there IS a time aspect.

What is the time frame in calendar terms?  Would 3GPP consider
"better" solutions to the problem?

> But, I don't understand why the first task should be to look for
> another solution, just for the sake of looking for another
> solution... 

I take it as central to the IETF's mission to produce standards that
not only work, but are as good as we can devise given the knowledge
that is available.  Within that mandate, minimizing complexity of a
protocol ("clean architecture") is an important goal.  Saying "this
does actually solve the problem" is the least praise that can be given
to technical work.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 May 2014 11:41:01 -0400

> ) is "Published RFC (A standards-track RFC is NOT required)".

Convenient!

So wouldn't a header field parameter for the Route, Service-Route, and 
Path headers do the job here?

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Tue, 6 May 2014 10:43:34 -0500

> ) is "Published RFC (A standards-track RFC is NOT required)".
[MB] Exactly. That's why I thought it would be a good option to consider,
in particular noting that's where the 3GPP P-headers are registered. [/MB]

---

From: Mary Barnes <[email-masked]>
Date: Tue, 6 May 2014 10:44:38 -0500

> Path headers do the job here?
[MB] That's possible as well. We would just need to make sure what's being
defined is general or it's clearly specified in which contexts it would be
used. [/MB]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 May 2014 12:05:52 -0400

On 5/6/14 11:44 AM, Mary Barnes wrote:
> On Tue, May 6, 2014 at 10:41 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>             From: Mary Barnes <[email-masked]
>             <mailto:[email-masked]>>
>
>
>         http://www.iana.org/__assignments/sip-parameters/__sip-parameters.xhtml#sip-__parameters-12
>         <http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-12>
>     So wouldn't a header field parameter for the Route, Service-Route,
>     and Path headers do the job here?
>
> [MB] That's possible as well. We would just need to make sure what's
> being defined is general or it's clearly specified in which contexts it
> would be used. [/MB]

The reason I suggested this is that the current draft implies that this 
might be used in a Service-Route it order to get it into Route headers 
of subsequent requests from the UA.

If it is intended only for 3gpp, then it should clearly specify this 
scope in the draft.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 6 May 2014 16:10:55 +0000

At the moment there is no normative statement in 3GPP specifications. As identified in another mail, there is a technical report examining the possibilities, and there is an agreed work item with 3GPP timescales to perform the normative work.

So yes, providing the response is to reasonably imminent, then any mechanism could be supported that fulfils the requirements.

Keith 

> From: dispatch [mailto:[email-masked]] On Behalf 
> Of Christer Holmberg
> Sent: 01 May 2014 16:21
> To: Dale R. Worley; [email-masked]
> >As far as I can tell, the draft refers to "signaling path", 
> but it does 
> >not distinguish whether the signaling path is the routing of 
> a single 
> >dialog, or whether it is broken into multiple dialogs by B2BUAs.  I 
> >don't think this changes the proposal technologically, but it should 
> >probably be stated explicitly somewhere.  It *is* a 
> requirement of the 
> >solution.
> 
> >dialog-establishing or out-of-dialog request is labeled 
> regarding which 
> >call leg it is within by the iotl parameter of the URI 
> currently used 
> >for routing (the topmost Route or the request URI).  This is a bit 
> >incorrect categorically, because:
> >
> I am not really sure what you mean by that. We are not 
> suggesting any changes to how URIs are used. The parameter 
> simply provides additional information to the consumer of the URI.
> 
> >rather a header parameter.  The Route header has header 
> parameters, but 
> >the request-URI doesn't; I suppose the analogous item is the 
> To header, 
> >which does have header parameters.
> 
> The parameter can, based on the use-case, be used both in the 
> SIP URI of a Route header, or in the Request-URI.
> 
> Regards,
> 
> Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 6 May 2014 16:10:54 +0000

I don't think we should be selecting a solution on the basis of what is the most convenient approval mechanism.

I think we should select the correct mechasism for performing this functionality, and then worry about the approval regime. I am not convinced the mechanism here need to be totally defined as an IMS specific - without the names of particular types of interface, the mechanism becomes fairly general purpose and could be useful for other SIP routeing networks outside IMS - in other words the mechanism could well be justified on standards track on that basis, but the registration of types of interface could be on a first come first served basis outside of the RFC structure.

Regards

Keith 

> Of Paul Kyzivat
> Sent: 06 May 2014 16:41
> So wouldn't a header field parameter for the Route, 
> Service-Route, and Path headers do the job here?
> 
> 	Thanks,
> 	Paul
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 6 May 2014 16:10:53 +0000

It is worth noting that some extensive analysis of the problem was performed in 3GPP over the pros and cons of various options.

That document is available at:

http://www.3gpp.org/DynaReport/24802.htm

I'm sure 3GPP participants would welcome comment, criticism or agreement with any part of that document. I do not guarantee that document will be updated as the study is regarded as essentially complete, but I would expect input to be reflected in ongoing work and proposals.

I'm fairly confident that as the issue is currently understood, it is information that relates to a URI, not to a specific header field or a request.

regards

Keith

________________________________
From: dispatch [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: 06 May 2014 15:31
To: Christer Holmberg
Cc: [email-masked]; [email-masked]
Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00

I thinks it's a bad idea to bend the rule and allow registration of SIP URI parameters in an informational document.   I haven't considered the problem you're trying to solve in detail, but ISTM that Dale had a good suggestion to use header field parameters.  And, if it's unique to 3GPP, you can define a P-header field.  Is there a reason why this would not work?

Mary

On Tue, May 6, 2014 at 1:30 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Perhaps the chairs and/or ADs could give some guidance?

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dale R. Worley
Sent: 6. toukokuuta 2014 0:28
To: Paul Kyzivat
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00

> From: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
>

Dale

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 May 2014 12:33:18 -0400

> I think we should select the correct mechasism for performing this functionality, and then worry about the approval regime.

I hear you. But the question is whether you can get sufficient support 
to work on a standards track document that is only of interest to 3gpp. 
If not, then you need to do something you can get done.

> I am not convinced the mechanism here need to be totally defined as an IMS specific - without the names of particular types of interface, the mechanism becomes fairly general purpose and could be useful for other SIP routeing networks outside IMS - in other words the mechanism could well be justified on standards track on that basis, but the registration of types of interface could be on a first come first served basis outside of the RFC structure.

In principle I agree with you. But then you need to take on the job of 
making the case that this is of broader relevance. I've been asking 
questions in the hope of teasing out what that might be, but so far I 
can't see any general use.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 May 2014 12:43:55 -0400

On 5/6/14 12:10 PM, DRAGE, Keith (Keith) wrote:
> It is worth noting that some extensive analysis of the problem was
> performed in 3GPP over the pros and cons of various options.
> I'm sure 3GPP participants would welcome comment, criticism or agreement
> with any part of that document.

OK. I just took a quick look. (I'm not highly motivated to read through 
the whole thing in depth.)

I see that a number of alternatives were considered, but those did not 
include a header field parameter for Route, Service-Route and Path.

The key seems to be Table 7.3.3.1 (Evaluation of compliance with the 
requirements in annex B). This table seems to justify the choice of a 
URI parameter. But I don't find any explanation for how evaluation of 
each alternative against each of the requirements was done. The values 
in the table aren't obviously correct to me. AFAICT my header parameter 
suggestion would get the same evaluation as the URI parameter does.

	Thanks,
	Paul

> I do not guarantee that document will be
> updated as the study is regarded as essentially complete, but I would
> expect input to be reflected in ongoing work and proposals.
> I'm fairly confident that as the issue is currently understood, it is
> information that relates to a URI, not to a specific header field or a
> request.
> regards
> Keith
> __
>
>     ------------------------------------------------------------------------
>     *From:* dispatch [mailto:[email-masked]] *On Behalf Of
>     *Mary Barnes
>     *Sent:* 06 May 2014 15:31
>     *To:* Christer Holmberg
>     *Cc:* [email-masked]; [email-masked]
>     *Subject:* Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00
>
>     I thinks it's a bad idea to bend the rule and allow registration of
>     SIP URI parameters in an informational document.   I haven't
>     considered the problem you're trying to solve in detail, but ISTM
>     that Dale had a good suggestion to use header field parameters.
>       And, if it's unique to 3GPP, you can define a P-header field.  Is
>     there a reason why this would not work?
>
>     Mary
>
>
>     On Tue, May 6, 2014 at 1:30 AM, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         From: dispatch [mailto:[email-masked]
>         <mailto:[email-masked]>] On Behalf Of Dale R. Worley
>         Cc: [email-masked] <mailto:[email-masked]>
>         Yes.  If we're going to document iotl at all, it should go into
>         the table of URI parameters.  But strictly speaking, it seems
>         that an informational RFC can't add an entry to this registry.
>
>         I don't know for certain, but it seems to me to be likely that
>         it can, and that would be a way around the apparent problem.
>
>         Dale
>
>         [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 May 2014 16:59:20 +0000

Hi,

> So wouldn't a header field parameter for the Route, Service-Route, and Path headers do the job 
> here?

No, because (as we have discussed) there are cases where the parameter is associated with the Request-URI.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 May 2014 17:09:45 +0000

Hi,

>> example, do you consider the commonly used "lr" parameter being "part 
>> of" a URI? In my opinion, it provides additional information about the 
>> URI - in the same way as "iotl" does.
>
> I believe that the "lr" URI parameter is an architectural error, and should have 
> been a header field parameter.

"lr" is just one example. Please take a look at the IANA list, and see whether you think all the other parameters are "part of" the URI...

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 May 2014 17:29:34 +0000

Hi,

>The key seems to be Table 7.3.3.1 (Evaluation of compliance with the requirements in annex B). >This table seems to justify the choice of a URI parameter. But I don't find any explanation for how >evaluation of each alternative against each of the requirements was done. The values in the table >aren't obviously correct to me. AFAICT my header parameter suggestion would get the same >evaluation as the URI parameter does.

It does not work if the iotl is associated with the Request-URI.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 May 2014 17:45:24 +0000

Hi,

>> I think we should select the correct mechasism for performing this 
>> functionality, and then worry about the approval regime.
>
> I hear you. But the question is whether you can get sufficient support to 
> work on a standards track document that is only of interest to 3gpp. 

Well, that's quite obvious - it's difficult for many people to find time even for things they DO support :)

Having said that, I think e.g. YOU have given very useful comments.

And, there is support for this in the 3GPP community, which is as good as any other support.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 May 2014 14:10:18 -0400

> It does not work if the iotl is associated with the Request-URI.

There is nothing to prevent having a Route header having the same URI as 
the R-URI.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 May 2014 14:16:17 -0400

> Having said that, I think e.g. YOU have given very useful comments.

You know, *I'll* comment on almost anything. :-)
(And I'll always find *something* that can be improved.)

> And, there is support for this in the 3GPP community, which is as good as any other support.

Yes, it is possible to go that way. It's just that then you will have to 
subject yourselves to comments from those who object. Getting consensus 
becomes harder. It is much harder to argue that you reject a "better" 
approach because it presents logistic problems within 3gpp.

Ultimately I think this is a matter for the dispatch chairs and the ADs 
to decide.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 May 2014 18:25:11 +0000

Hi,

>>> The key seems to be Table 7.3.3.1 (Evaluation of compliance with the requirements in annex B). >>This table seems to justify the choice of a URI parameter. But I don't find any explanation for how >>evaluation of each alternative against each of the requirements was done. The values in the table >>aren't obviously correct to me. AFAICT my header parameter suggestion would get the same >>evaluation as the URI parameter does.
>>
> There is nothing to prevent having a Route header having the same URI as the R-URI.

Not sure how that works when the R-URI e.g. addresses an end-user, but is "consumed" by another node, e.g. the registrar serving the end-user (e.g. the home S-CSCF in 3GPP). I think you would have to add a Route header that points to the actual registrar/S-CSCF, and the starting point (which can be an S-CSCF in another operator network) may not even have that information (there is no registration path between the S-CSCFs).

Maybe it's doable somehow, but I just think it would complicate things, and would require additional procedures, when you can avoid that by using a URI parameter.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 May 2014 14:57:03 -0400

> Not sure how that works when the R-URI e.g. addresses an end-user, but is "consumed" by another node, e.g. the registrar serving the end-user (e.g. the home S-CSCF in 3GPP). I think you would have…

I don't follow. The R-URI that is "consumed" by the registrar is the 
AOR. Are you imagining that this parameter will be present in the AOR 
all the time? If not, who adds it, and when? Whoever adds it to the AOR 
could just as easily add a Route header. That Route header could have 
the full AOR and the header parameter. Or it could just have the domain 
from the AOR and the header parameter.

> Maybe it's doable somehow, but I just think it would complicate things, and would require additional procedures, when you can avoid that by using a URI parameter.

I don't know if it complicates things because I don't know what 
complications will be needed to put this parameter in, independent of 
the mechanism. I can see how Service-Route could have this added during 
registration. Other than that I have no clue who would do what. 
Service-Route won't get anything into the R-URI.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 May 2014 19:22:06 +0000

Hi,

>>>>> The key seems to be Table 7.3.3.1 (Evaluation of compliance with the requirements in annex >>>>> B). This table seems to justify the choice of a URI parameter. But I don't find any explanation >>>>> for how evaluation of each alternative against each of the requirements was done. The values >>>>> in the table aren't obviously correct to me. AFAICT my header parameter suggestion would get >>>>> the same evaluation as the URI parameter does.
>>>>
>> Not sure how that works when the R-URI e.g. addresses an end-user, but is "consumed" by 
>> another node, e.g. the registrar serving the end-user (e.g. the home S-CSCF in 3GPP). I think you >> would have to add a Route header that points to the actual registrar/S-CSCF, and the starting 
>> point (which can be an S-CSCF in another operator network) may not even have that information >> (there is no registration path between the S-CSCFs).
>
> I don't follow. The R-URI that is "consumed" by the registrar is the AOR. Are you imagining that this > parameter will be present in the AOR all the time? If not, who adds it, and when? Whoever adds it > to the AOR could just as easily add a Route header. That Route header could have the full AOR and > the header parameter. Or it could just have the domain from the AOR and the header parameter.
>
>> Maybe it's doable somehow, but I just think it would complicate things, and would require 
>> additional procedures, when you can avoid that by using a URI parameter.
>
> I don't know if it complicates things because I don't know what complications will be needed to put > this parameter in, independent of the mechanism. I can see how Service-Route could have this 
> added during registration. Other than that I have no clue who would do what. 

Again, perhaps it's doable, but you would have to specify how that extra Route looks like etc. And, I don't see why one should have to do that, if you get the same result by using a SIP URI parameter.

In addition, there is one use-case where an existing FCI is used to carry a URI. And, that URI may now also contain an iotl. If we would use something else to carry the iotl, we would have to re-define that FCI (currently it's defined to carry a URI value only), which could cause backward compatibility issues. 

Of course, if the suggested SIP URI parameter solution doesn't work, we will have to do that, but nobody has said why a SIP URI parameter would not work. I still also think that it fits semantically.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 6 May 2014 15:47:31 -0400

> From: "DRAGE, Keith (Keith)" <[email-masked]>

> http://www.3gpp.org/DynaReport/24802.htm

Specifically, the latest version (12.0.0) can be obtained at
http://www.3gpp.org/ftp/Specs/archive/24_series/24.802/24802-c00.zip .
That URL retrieves a ZIP file containing a DOC file named
24802-c00.doc.

The list of requirements is in Annex B.2.3.  The detailed list of
proposals is in section 7.  Table 7.3.3.1 comparing the proposals
against the requirements is on page 41.  Pros and cons of the
proposals are listed in section 9.

This document really should be a reference in the draft, since it is
the technical justification for the draft.

A first look:

Looking at the comparison table, I see that most entries are "Yes",
that is, the proposal satisfies the requirement.  Several others are
"RFC required", "New IANA procedure required", or similar things --
but I don't see those as a problem, since we are considering an RFC
and that can create new IANA procedures.

The bulk of the entries that aren't "Yes" are "Local policy based on
interoperator agreement is required".  I'm not sure where those come
from.  I suspect that the issue is that the current 3GPP architecture
isn't transparent with regard to the new item (header fields,
P-Charging-Vector value, feature capability indication), and so the
gatewaying specifications between carriers would need to be updated.

None of the entries suggest that any of the proposals would not work
technically.

What seems to be missing is a requirement covering the most
interesting feature of the iotl proposal:  A route list can be
provided that can cause the request to be labelled differently during
each of a series of hops between proxies without any special
processing required of the proxies.  However this benefit is listed in
the pro/con analysis of section 9.  Contrarily, the analysis of other
proposals (e.g., section 7.3.2.4) seems to consider that the CSCFs
will know when to insert and remove scenario indicators anyway.  So
it's not clear that this is truly a requirement.

Dale

---

From: "Calme, James A (Jim)" <[email-masked]>
Date: Wed, 7 May 2014 16:09:12 +0000

Hi,

Looking at the ABNF for this new parameter it would appear that only a single value is expected to used.
iotl-param    = iotl-tag "=" iotl-value
 iotl-tag      = "iotl"
 iotl-value    = "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA"
                 / "homeA-visitedA" /" visitedA-homeB" / gen-value

Given the current set of values, it would seem reasonable that they would be mutually exclusive. But do you expect this to always be true? Would it be possible that if additional values are defined that they could compliment the currently set, i.e., should the syntax allow one or more values to be included?

Jim

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 May 2014 17:46:27 +0000

Hi Jim,

Currently there are no use-cases which, for a given URI, would require multiple values.

But, if people think it would be useful to allow it for possible future usage, we can for sure modify the ABNF to allow it.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

"Calme, James A (Jim)" <[email-masked]> wrote:

Hi,

Jim

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 7 May 2014 14:09:22 -0400

> In addition, there is one use-case where an existing FCI is used to
> carry a URI.

As far as I can figure out, "FCI" means "Forward Call Indicator",
which is a field in the IAM message.  I can't find any definition of
its structure in any RFC, but all uses of the term suggest that it is
a group of bit-fields, not a character string.

I also can't find "FCI" in 3GPP TR 24.802, "Indication of Network to
Network Interface (NNI) routeing scenarios in Session Initiation
Protocol (SIP) requests in the IP Multimedia Subsystem (IMS)", which
Keith says is the technical analysis behind this draft.

Can you present us this use-case, or provide us with a reference?  And
why does it not appear in 24.802?

Dale

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 7 May 2014 18:22:02 +0000

I support the ability to signal multiple values

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards  
AT&T Standards and Industry Alliances
+1-609-903-3360
[email-masked]

> On May 7, 2014, at 1:46 PM, "Christer Holmberg" <[email-masked]> wrote:
> 
> Hi Jim,
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 May 2014 18:54:31 +0000

Hi,

>> In addition, there is one use-case where an existing FCI is used to carry a URI.
>
> As far as I can figure out, "FCI" means "Forward Call Indicator", which is a field in the IAM message.  > I can't find any definition of its structure in any RFC, but all uses of the term suggest that it is a 
> group of bit-fields, not a character string.
>
> I also can't find "FCI" in 3GPP TR 24.802, "Indication of Network to Network Interface (NNI) routeing > scenarios in Session Initiation Protocol (SIP) requests in the IP Multimedia Subsystem (IMS)", which > Keith says is the technical analysis behind this draft.

Sorry for the Christer-Paul slang - I meant Feature-Capability Indicator :)

> Can you present us this use-case, or provide us with a reference?  And why does it not appear in 
> 24.802?

I don't know, but it would good to add it there.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 7 May 2014 15:20:31 -0400

> > Not sure how that works when the R-URI e.g. addresses an end-user,
> > but is "consumed" by another node, e.g. the registrar serving the
> > end-user (e.g. the home S-CSCF in 3GPP). I think you would have to
> > add a Route header that points to the actual registrar/S-CSCF, and
> > the starting point (which can be an S-CSCF in another operator
> > network) may not even have that information (there is no
> > registration path between the S-CSCFs).
> 

Let me raise an alternative proposal, partly to show that alternatives
exist, and partly to illustrate what I think is Paul's point.

The proposal is that the iotl information is encoded not in a URI
parameter, but a header of the URI.  (This does get around any
semantic objection, because it is established that a 'header' is a
decoration of the base URI, not intrinsically part of it.)

There seem to be no published examples for me to crib from, so I'm
going to have to improvise, and likely will make some mistakes.  But
this should illustrate the point.

We want the path of the call to be:

A to VisitedA, presumably with no iotl, since it's all within one
    network (and A doesn't know what iotl to use)
VisitedA to HomeA with iotl visitedA-homeA
HomeA to HomeB with iotl homeA-homeB
HomeB to VisitedB with iotl homeB-visitedB
VisitedB to B, again presumably with no iotl (and there seems to be no
    relevant iotl value)

Then, departing from VisitedA, the request would look like:

INVITE B SIP/2.0
Route: <HomeA;lr?Iotl=visitedA-homeA>
Route: <HomeB;lr?Iotl=homeA-homeB>
Route: <VisitedB;lr?Iotl=homeB-visitedB>
From: <A>;tag=xxx
To: <B>;tag=yyy

Decorating B is problematic.  While a request-URI is permitted
syntactically to have a header, the process for forming a request in
RFC 3261 prevents headers from appearing on request-URIs.  So we
should probably avoid putting headers on request-URIs.

Of course, this may not matter, as it's not clear that the hops from
the last proxy/B2BUA to B will need an iotl, as those hops are always
within one network and always after any network-provided services.
(Since any such services would show up as a routing, and this hop is
after all routings.)

OTOH, one could provide an additional Route duplicating the
request-URI to carry an iotl for those hops:

INVITE B SIP/2.0
Route: <HomeA;lr?Iotl=visitedA-homeA>
Route: <HomeB;lr?Iotl=homeA-homeB>
Route: <VisitedB;lr?Iotl=homeB-visitedB>
Route: <B;lr?Iotl=homeB-visitedB>
From: <A>;tag=xxx
To: <B>;tag=yyy

Would this be processed correctly?

When the request arrives at VisitedB, it will look like:

INVITE B SIP/2.0
Route: <VisitedB;lr?Iotl=homeB-visitedB>
Route: <B;lr?Iotl=homeB-visitedB>
From: <A>;tag=xxx
To: <B>;tag=yyy

VisitedB must remove the topmost Route value.  One possibility is that
it sees that both the remaining Route and the request-URI are both in
its domain and are the same, and so it will delete the Route and
forward the INVITE to B's binding:

INVITE Bbinding SIP/2.0
From: <A>;tag=xxx
To: <B>;tag=yyy

When this arrives at B, B accepts it.

An alternative is that VisitedB replaces B in the Route header with
B's binding:

INVITE B SIP/2.0
Route: <Bbinding;lr?Iotl=homeB-visitedB>
From: <A>;tag=xxx
To: <B>;tag=yyy

When this arrives at B, B deletes the Route value (because that is its
binding), and accepts the request (because the request-URI is its
AOR).  Or maybe B accepts all INVITEs that arrive at it because it is
a UA and doesn't forward requests at all.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 7 May 2014 15:34:47 -0400

> "lr" is just one example. Please take a look at the IANA list, and
> see whether you think all the other parameters are "part of" the
> URI...

True, I looked and the situation isn't as clear as I thought.  But all
of the URI parameters (other than 'lr') seem to be examined only by a
device constructing a request from the URI, or a device "within the
domain" of the URI; devices that the request is simply transiting
treat the parameter opaquely.  'lr' seems to be the exception, in that
it must be interpreted by the proxies of every domain.

And the purpose of 'iotl' seems to be to modify the process of network
transit, not trigger specific processing at the proxies (or B2BUAs?)
designated by the URIs containing them.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 May 2014 19:41:02 +0000

Hi,

>> "lr" is just one example. Please take a look at the IANA list, and see 
>> whether you think all the other parameters are "part of" the URI...
>
> True, I looked and the situation isn't as clear as I thought.  But all of the URI parameters (other than > 'lr') seem to be examined only by a device constructing a request from the URI, or a device "within > the domain" of the URI; 

It still doesn't mean that the parameter is "part of" the URI.

> devices that the request is simply transiting treat the parameter opaquely.  
> 'lr' seems to be the exception, in that it must be interpreted by the proxies of every domain.
>
> And the purpose of 'iotl' seems to be to modify the process of network transit, not trigger specific 
> processing at the proxies (or B2BUAs?) designated by the URIs containing them.

'iotl' may trigger actions both at intermediary nodes, and at the node consuming the URI (i.e. the endpoint of the traffic leg).

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 7 May 2014 15:51:35 -0400

> [...] I am not convinced the mechanism here need to be totally
> defined as an IMS specific - without the names of particular types
> of interface, the mechanism becomes fairly general purpose and could
> be useful for other SIP routeing networks outside IMS - in other
> words the mechanism could well be justified on standards track on
> that basis, [...]

I think part of the difficulty is that those of us not in contact with
3GPP don't have a good idea what the mechanism is intended to do.

One possibility is that it's simply to notify, say, a proxy in A's
home network that when the request arrives, the request has had
certain service-specific processing applied and that certain other
service-specific processing has not yet applied.  In that case, the
iotl is a modification of "where this request is to be sent at this
stage", and a URI parameter is clearly acceptable; the device
responsible for the base URI is the only one that needs to process the
attached iotl value.  In the context of Figure 1 of the draft,
iotl=visitedA-homeA modifies what happens *at* proxy/B2BUA "ORIG HNW".

With this possibility, it's not clear that there are any
interoperability issues, or that is anything that needs to be
standardized.  Although it would be nice to record that 'iotl' is the
parameter 3GPP uses to specify this information.

Another possibility is that the iotl modifies *how the request
progresses from one Route point to another*.  In the context of Figure
1, iotl=visitedA-homeA modifies what happens on the path (the sequence
of +'s) from "ORIG VNW" to "ORIG HNW".

This possibility is altogether heavier, because devices that aren't
within any of the domains of the routing URIs may need to see and act
on the iotl values.  (Maybe this isn't an issue in 3GPP, but it is in
the general case.)  This is like the Resource-Priority header.  And in
this case, it's important that everybody does it the same way, and
that the semantics are clearly structured.  But conversely, it isn't
information that is particularly attached to the URI.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 May 2014 19:55:13 +0000

Hi,

> The proposal is that the iotl information is encoded not in a URI parameter
>, but a header of the URI.  (This does get around any semantic objection, because 
> it is established that a 'header' is a decoration of the base URI, not intrinsically 
> part of it.)

Please show me some text justifying your claim.

Again, a big part of the existing SIP URI parameters (including parameters defined in 3261) are using similar semantics, so I think it very strange that someone suddenly decides that it is semantically wrong.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 7 May 2014 15:59:33 -0400

> Sorry for the Christer-Paul slang - I meant Feature-Capability Indicator :)

OK.

But there's a treacherous problem:  If device A attaches an iotl value
to a URI in a FCI value, and that FCI value is read and used by device
B, device A has to know where device B sits in the network, and what
iotl value will be appropriate for device B to use when it generates a
request using that URI.

My understanding is that iotl values are added to requests by
proxies/B2BUAs early in the routing of a request.  This makes sense,
because the router needs to know both the source and destination
locations of the request, and it is *sitting there*, so it knows all
of the relevant policies.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 May 2014 20:09:32 +0000

Hi,

> But there's a treacherous problem:  If device A attaches an iotl value to a URI in a FCI value, and 
> that FCI value is read and used by device B, device A has to know where device B sits in the 
> network, and what iotl value will be appropriate for device B to use when it generates a request 
> using that URI.

Sure, and this will only be used in a very specific use-case, when that information is known.

>My understanding is that iotl values are added to requests by proxies/B2BUAs early in the routing >of a request.  This makes sense, because the router needs to know both the source and destination >locations of the request, and it is *sitting there*, so it knows all of the relevant policies.

The URI provided in the FCI will later be used in the R-URI of an INVITE.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 7 May 2014 16:09:52 -0400

> From: "Calme, James A (Jim)" <[email-masked]>

> Given the current set of values, it would seem reasonable that they
> would be mutually exclusive. But do you expect this to always be
> true? Would it be possible that if additional values are defined
> that they could compliment the currently set, i.e., should the
> syntax allow one or more values to be included?

RFC 3261 specifies that there can be only one URI parameter of a
single name attached to a URI.  OTOH, given that <iotl-value> can
produce <gen-value>, there's no reason that one cannot define values
that mean "the effect of 'homeA-homeB' plus special feature XYZ".

Perhaps the thing to do is to define a particular character to mean
"separator of multiple values" in <iotl-value>s.  This allows people
who want to have combined iotl values in the future a consistent way
to do it.

If we want to avoid the necessity of quoting <iotl-value>, we are
restricted to <token>:

      token       =  1*(alphanum / "-" / "." / "!" / "%" / "*"
                     / "_" / "+" / "`" / "'" / "~" )

Which allows . ! % * _ + ` ' ~ for delimiters.

Dale

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 8 May 2014 02:27:24 +0000

one possibility is to simply make it standard track with a sufficient warning in the abstract and intro about the environment for which it is intended to be used for

I skimmed the draft but did not really get the motivation for the design - perhaps at next meeting we should spend 5 minutes filling me in on it. 

I will note our agreement with 3GPP is they bring us problems not solutions and then we try and work on a solution together.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 May 2014 12:10:44 +0000

Hi Cullen,

>I will note our agreement with 3GPP is they bring us problems not solutions and then we try and work on a solution together. 

The draft does try to explain what this is used for.

And, the draft does suggest a solution. But, if it doesn't work, or if it for some other reason can't be used, of course we need to look at something else.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 May 2014 11:13:17 -0400

> Route: <VisitedB;lr?Iotl=homeB-visitedB>

I think you meant:

INVITE B SIP/2.0
Route: <HomeA;lr>;Iotl=visitedA-homeA
Route: <HomeB;lr>;Iotl=homeA-homeB
Route: <VisitedB;lr>;Iotl=homeB-visitedB
From: <A>;tag=xxx
To: <B>;tag=yyy

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 May 2014 11:31:14 -0400

> It still doesn't mean that the parameter is "part of" the URI.

It is part of the URI by definition:

    SIP-URI       =  "sip:" [ userinfo ] hostport
                     uri-parameters [ headers ]

It is also by definition an identifier of a resource. It is a *name*, 
like your name. It is assigned by the owner of the resource, or by 
someone acting on behalf of the owner of the resource. It isn't really 
proper for others who simply want to *reference* that resource to change 
its name. Instead, we put information on how to reference the resource 
in other places, such as in header parameters.

This is a philosophical point. I don't know if it is written down 
anywhere. Certainly it has been violated. Yet I think it remains the 
right way to view things.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 May 2014 11:37:21 -0400

> I support the ability to signal multiple values

When I saw that it can be put into Path and Service-Route, I immediately 
assumed that there might be multiple values. I was surprised when 
Christer said that there would only be one at a time.

But, it did lead me to post questions about how the "current" value is 
to be determined. I had some questions about that earlier in this 
thread. That discussion was squelched when Christer said there will only 
be one.

So if multiple values are to be allowed, then more explanation is needed 
about the details of the semantics in those cases.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 May 2014 17:42:36 +0000

Hi,

>>>> see whether you think all the other parameters are "part of" the URI...
>>>
>>> True, I looked and the situation isn't as clear as I thought.  But 
>>> all of the URI parameters (other than > 'lr') seem to be examined 
>>> only by a device constructing a request from the URI, or a device 
>>> "within > the domain" of the URI;
>>
> It is also by definition an identifier of a resource. It is a *name*, like your name. It is assigned by 
> the owner of the resource, or by someone acting on behalf of the owner of the resource.

I am not really sure I understand, but I think there are many cases ("lr" is only one example - eventhough it is widely used) where that is not the case.

> It isn't really proper for others who simply want to *reference* that resource to change its name. 
> Instead, we put information on how to reference the resource in other places, such as in header 
> parameters.
>
> This is a philosophical point. I don't know if it is written down anywhere. Certainly it has been 
> violated. Yet I think it remains the right way to view things.

If we have chosen a path, and we can't clearly show that it's semantically wrong or breaks the protocol,  I think we should stick to it. Otherwise it is very difficult to design anything, and it only causes delays and frustration, if people suddenly decide to become philosophical and then decide that we can no more do things in certain ways...

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Thu, 8 May 2014 15:11:45 -0400

Since RFC 3261 section 19.1.4 allows some parameters to be added or
removed without it impacting equality, I'm not sure that I understand the
arguments against allowing iotl to be included within a sip-uri.  It may
or may not be the best location for it; however it doesn't seem too
different from the rest of the parameters that get shoved into the sip-uri
(especially if needs to be received within a Request-URI).

The following are the sip-uri parameters indicated within IANA: aai, bnc,
cause, ccxml, comp, content-type, delay, duration, extension, gr, locale,
lr, m, maddr, maxage, maxstale, method, method (yes IANA shows two method
parameters), ob, param[n], play, postbody, repeat, sg, sigcomp-id, target,
transport, ttl, user, and voicexml.

> Sent: Thursday, May 08, 2014 1:43 PM
> like your name. It is assigned by
> I am not really sure I understand, but I think there are many cases
> ("lr" is only one example - eventhough it is widely used) where that is
> not the case.
>
> anywhere. Certainly it has been
> If we have chosen a path, and we can't clearly show that it's
> semantically wrong or breaks the protocol,  I think we should stick to
> it. Otherwise it is very difficult to design anything, and it only
> causes delays and frustration, if people suddenly decide to become
> philosophical and then decide that we can no more do things in certain
> ways...
>
> Regards,
>
> Christer

-- 

See why you should attend BroadSoft Connections 2014<http://broadsoftconnections.com/>

This email is intended solely for the person or entity to which it is 
addressed and may contain confidential and/or privileged information. If 
you are not the intended recipient and have received this email in error, 
please notify BroadSoft, Inc. immediately by replying to this message, and 
destroy all copies of this message, along with any attachment, prior to 
reading, distributing or copying it.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 8 May 2014 16:27:41 -0400

> Route: <VisitedB;lr>;Iotl=homeB-visitedB

In this instance, I meant to use "headers" rather than
header-parameters, to illustrate that possibility.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 8 May 2014 16:35:19 -0400

> ("lr" is only one example - eventhough it is widely used) where that
> is not the case.

Which URI parameters, other than "lr", are routinely manipulated by
SIP entities outside of the domain of the URI?  I didn't spot any
myself, though I didn't examine the list comprehensively.

> semantically wrong or breaks the protocol,  I think we should stick
> to it.

Uh, who is the "we" that has chosen a path?  Currently, 3GPP has made
a proposal, but (as far as I can tell from the document referenced by
Keith), two alternatives (a header parameter and a "header" component)
are quite similar relative to the advantages listed in the technical
assessment document.  And that document doesn't actually cover the
various desired scenarios that are quoted in this discussion.

As Cullen says, "I will note our agreement with 3GPP is they bring us
problems not solutions and then we try and work on a solution
together."

> What I meant was that there can't be "iotl" values in the
> Request-URI and Route(s) at the same time.

I am surprised that that idea.  It seems natural to me that (assuming
iotl is a URI parameter), the request-URI and the Route values can
each have their own iotl.  The "current" iotl is the one on the URI
that currently controls routing of the request, either the topmost
Route, or if one does not exist, the request-URI.  (This is assuming
all Route URIs have "lr"; if that isn't true, further rules are
needed.)

That allows the transport segment controlled by each Route URI to be
within a different call leg.  I've always assumed that is one of the
desired features of this proposal.

If there is only one iotl applicable to the whole set of URIs, then
many more solutions become plausible.

> Please show me some text justifying your claim.

It's not particularly well described in RFC 3261, but when a request
is to be sent to a URI containing a headers component, the headers
component is removed and used to construct additional headers in the
request.  Hence, devices outside the domain of the URI are intended to
manipulate the headers component of a URI.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 May 2014 21:37:13 +0000

Hi,

> Which URI parameters, other than "lr", are routinely manipulated by SIP entities outside of the 
> domain of the URI?  I didn't spot any myself, though I didn't examine the list comprehensively.

What do you mean by "routinely manipulated"?

>> it.
> Uh, who is the "we" that has chosen a path? 

The IETF community, that has defined the existing URI parameters.

> Currently, 3GPP has made a proposal, but (as far as I can tell from the document referenced by 
> Keith), two alternatives (a header parameter and a "header" component) are quite similar relative > to the advantages listed in the technical assessment document.  And that document doesn't 
> actually cover the various desired scenarios that are quoted in this discussion.

The plan is to add the header parameter alternative to that document.

More on the headers component below.

> As Cullen says, "I will note our agreement with 3GPP is they bring us problems not 
> solutions and then we try and work on a solution together."

Sure, and I am happy to discuss alternatives (which we are currently doing :). 

But, people suggesting alternatives should also show why a suggested solution does not work.

>> What I meant was that there can't be "iotl" values in the Request-URI 
>> and Route(s) at the same time.
>
> I am surprised that that idea.  It seems natural to me that (assuming iotl is a URI parameter), the 
> request-URI and the Route values can each have their own iotl.  The "current" iotl is the one on the > URI that currently controls routing of the request, either the topmost Route, or if one does not 
> exist, the request-URI.  (This is assuming all Route URIs have "lr"; if that isn't true, further rules are
> needed.)
>
> That allows the transport segment controlled by each Route URI to be within a different call leg.  
> I've always assumed that is one of the desired features of this proposal.
>
> If there is only one iotl applicable to the whole set of URIs, then many more solutions become 
> plausible.

As long as we can specify how to determine the "current", we can allow whatever combinations.

> It's not particularly well described in RFC 3261, but when a request is to be sent to a URI containing > a headers component, the headers component is removed and used to construct additional 
> headers in the request.  Hence, devices outside the domain of the URI are intended to manipulate > the headers component of a URI.

But, how is that semantically more correct? When the INVITE is sent, nobody is going to remove the Iotl headers components from the URIs and construct additional Iotl headers to the request. 

If I understand you correctly, you are suggesting to define a new SIP header field (Iotl) that will never we used as a "standalone" header field in a request - only as a headers component in a URI...?

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Fri, 9 May 2014 07:01:21 -0400

> Which URI parameters, other than "lr", are routinely
> manipulated by SIP entities outside of the domain of
> the URI?

Parameters that are malformed or problematic routinely get removed or
adjusted if configured or chose to remove/adjust the parameter instead of
rejecting the request or relaying the malformed or problematic URI.

Since RFC 3261 changed the RFC 2543 equality rules, parameters with
default values are no longer routinely manipulated.

> It's not particularly well described in RFC 3261, but
> when a request is to be sent to a URI containing a
> headers component, the headers component is removed
> and used to construct additional headers in the request.
> Hence, devices outside the domain of the URI are
> intended to manipulate the headers component of a URI.

RFC 3261 sections 19.1.1 and 19.1.2 (Table 1) indicate that headers are
not allowed within Route.

--