Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules

[Laura Liess <[e-mail]>]

2012/1/23 Firoze M. Zahidur  Rahman <[e-mail]>:
> Hi
>
> Thanks a lot for the clarification. I think my proposal and the your discussion point is not same. My proposal was a URNs like
>
> Alert-Info: <URN:alert:service:normal.call-waiting.forward>
> Alert-Info: <URN:alert:source:family.friend.internal.unclassified>
> Alert-Info: <URN:alert:priority:high.normal>

> etc
>
> Or may be
>
> Alert-Info: <URN:alert:source:family.friend.internal.unclassified>, <URN:alert:service:normal.call-waiting.forward>, <URN:alert:priority:high.normal>
>
> Or something similar. This will help the UA to decide e.g. regarding "service" -priority is normal then call-waiting and finally forward. So UA will try to alert for normal call, if not possible (may be busy in another call) notify for call-waiting or finally notify for forwarding. And the priority for the selection can be determined by the order of appearance.
>
If I understand correctly, in your proposal the rendering for
<URN:alert:service:normal.call-waiting.forward> would depend of the
state of the end device. The rendering for this URN would be the
"normal" when the end device is idle and "call-waiting" or "forward"
when the device is "busy". I am not an expert for URIs/URNs, but I
would say this is not allowed by the definition of the URNs. The RFC
1737 describes the requirements for URNs:

 o Global scope: A URN is a name with global scope which does not
     imply a location.  It has the same meaning everywhere.

   o Global uniqueness: The same URN will never be assigned to two
     different resources.

   o Persistence: It is intended that the lifetime of a URN be
     permanent.  That is, the URN will be globally unique forever, and
     may well be used as a reference to a resource well beyond the
     lifetime of the resource it identifies or of any naming authority
     involved in the assignment of its name.

I think your proposal does not allign with the definition of the URNs.
It can not be that the meaning of a URN depends on the algorithm at
the receiving end device. I am not aware of examples where one URN
contains names with contradictory meanings and using such syntax would
be, if not forbidden, very confusing. I think it would be difficult to
pass this syntax through the IESG review. The syntax we have now was
discussed and reviewed by IETF experts in the past. I am not willing
to change it now into a syntax which may be incorrect.

And I really  don't see why
<URN:alert:service:normal.call-waiting.forward> should be easier to
implement than
 <URN:alert:service:normal> <URN:alert:service:call-waiting>
<URN:alert:service:forward>. The algorithm described in the draft is
not mandatory, it is just an example. You are free to use an algorithm
of your choice.

However, it would make sense for me to consider your use case within
the priority rules in Section 7, because they are mandatory. We
eventually ( if the WG agrees to that) could add following at the end
of the text inside the brackets in the requirement b.: "(because it
does not recognize the URN or the URN's effect is precluded by
preceding URNs   *** or not compatible with the current state of the
end device or explicitely not desired ***  )" . (The new text is
between ***.) Would you agree to that?

Regards
Laura
.

> And I am not sure if this will increase no of IANA registration. The registration can follow
>
> service RFCXXXX
> source RFCYYYY
>
> etc.
>
> Best Regards
>
> Jewel
>
> -----Original Message-----
> From: Laura Liess [mailto:[e-mail]]
> Sent: Monday, January 23, 2012 8:54 PM
> To: Firoze M. Zahidur Rahman
> Cc: [e-mail]; Paul Kyzivat; Roland Jesske
> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules
>
> 2012/1/21 Firoze M. Zahidur  Rahman <[e-mail]>:
>> Hi
>>
>> It will be very nice if you please can refer the discussion date or thread of the multiple value discussion. I am not able to find it.
>
> As Paul already pointed out we already had this discussion, not only once.
>
> The first discussion was in BLISS, back in 2009.  (This draft was
> first submitted in BLISS, then moved to DISPATCH, then we got our own
> miniWG SALUD. ) In the first versions of the draft in BLISS followed a
> similar direction as you propose. See Section 7.3 in
> http://tools.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt
>  .
> In http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html
> Adam Roach pointed out that we have to register all combinations with
> IANA an "If someone adds another semantic dimension, the size of the
> registry continues to grow exponentially".
>
> The second discussion on this issue was in SALUD, see  the messages
> around  http://www.ietf.org/mail-archive/web/salud/current/msg00038.html
> . We call  this issue "multiple URN vs. single URN". Again, we came to
> the conclusion that also "single URN" is much more simple to implement
> for the receiving UA, we run with it into the problem identified by
> Adam, the IANA registry grow exponentially when new values are
> registred. With "multiple URNs",  we don't have this problem.
>
> A receiving UA has to be able to deal with combinations of Alert-Info
> URNs anyway because  more than one SIP network elements in the message
> path (the sending UA, proxies, B2BUAs) may insert Alert-Info URNs.
>
> Kind regards
> Laura
>
>
>
>
>
>
>
>
>
>>
>> However, there are couple of things I wanted to highlight in my first mail.
>>
>> 1. URN string format - bundling multiple values (on which I may be wrong as this is already discussed and decided - I will go through the earlier mails from the archive to clarify my understanding)
>>
>> 2. Values of Priority Field - Can we use numbers 0-9 or 00-99
>>
>> 3. Can we have another category to define UA/device reaction/behavior?
>>
>> Particularly for 2 and 3 the reason I am proposing this is
>>
>> 1. Alert-Info can be present in INVITE and if it is present in Invite then it will be nice to have a mechanism to guide/standardize the handling process/logic of the Alert-Info for the devices receiving Alert-Info
>>
>> 2. As we have multiple URN and URNs defining the service, source, priority etc. I assume the priority is the priority for the session/call. If we implement priority as a number then sorting on the priority number for currently ongoing sessions can be done at the device side - and logics can be implemented like force disconnect for higher priority calls, do not notify for lower priority calls, notify back the user for certain priority calls, divert if priority is less than some specific values. And we can leave it up to the implementation.
>>
>> With these features I think we will be able to standardize the implementation of Reverse Ring Back Tone, Custom Ringtone/Notification decided by caller, Call Back Notification Services (where caller will be notified whenever the line is free), Handling of Promotional/Low Priority Calls (Voice or Message/SMS Broadcasts) etc.
>>
>> Thanks & Regards
>>
>> JEWEL
>> Firoze M Zahidur Rahman
>> F  [phone], [phone]
>> 3 [phone], [phone]
>>
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Paul Kyzivat
>> Sent: Saturday, January 21, 2012 1:50 AM
>> To: [e-mail]
>> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules
>>
>> On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote:
>>> Hi
>>>
>>> Its not really usage of lesser no of bytes, the overall idea was to accommodate multiple values in the same URN. As this extension enables UA or devices to choose/implement features as per internal implementation logic - my idea was to make the structure as - all values in single line. So that while implementing device will not have to think about same category multiple times. Even if same category multiple times is allowed - it will completely refresh/overrule earlier appearance.
>>>
>>> And the order of appearance wise priority (I think corrent approach is also same, priority is decided by order of appearance of URN in header field) also handles the priority decision making process unchanged.
>>>
>>> Instead of comma(,) we can use dot(.) or slash(/) separated values may be. Or we can find some other way to make it URI compatible. But that can be though/found out if everyone thinks that bundling all values of a category in single URN makes sense.
>>
>> If you look through the salud mail archives you will see that combining
>> things into a single URN was proposed and discussed, but we settled on
>> what we have now.
>>
>>        Thanks,
>>        Paul
>>
>>> Thanks&  Best Regards
>>>
>>> Jewel
>>>
>>> ________________________________________
>>> From: [e-mail] [[e-mail]] On Behalf Of Paul Kyzivat [[e-mail]]
>>> Sent: Friday, January 20, 2012 11:43 PM
>>> To: [e-mail]
>>> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules
>>>
>>> On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote:
>>>> Hi
>>>>
>>>> Greetings!
>>>>
>>>> I am very new to this area. Advance apologies if my ideas sounds completely misaligned.
>>>>
>>>> I found current way of using multiple Alert-Info URNs and Priority Rules a bit difficult to use and implement. I can see that we have 6 fixed alert-categories and the Alert URN Format is
>>>>
>>>> "URN:alert:" alert-identifier
>>>>
>>>> And format of alert-identifier is
>>>>
>>>> alert-category ":" alert-indication
>>>>
>>>> and alert-indication is a single value.
>>>>
>>>> If we can allow to include multiple value in alert-indication separated by comma (,) and the order of appearance will decide the order of priority for the alert-indication value then I think it will be easy to implement from the device side.
>>>>
>>>> So instead of sending multiple URN like
>>>> URN:alert:source:family
>>>> URN:alert:source:friend
>>>> URN:alert:source:internal
>>>> URN:alert:source:unclassified
>>>>
>>>> device will send URN as
>>>>
>>>> URN:alert:source:family,friend,internal,unclassified
>>>
>>> In the above you have not included the header. It would really be:
>>>
>>> Alert-Info: URN:alert:source:family
>>> Alert-Info: URN:alert:source:friend
>>> Alert-Info: URN:alert:source:internal
>>> Alert-Info: URN:alert:source:unclassified
>>>
>>> and your preference would seem to be:
>>>
>>> Alert-Info: URN:alert:source:family,friend,internal,unclassified
>>>
>>> But the latter cannot work. The key point is that Alert-Info takes URIs
>>> as arguments (including URNs), which can be separated by commas or as
>>> separate header fields. Because of that, in your latter case, "friend"
>>> is syntactically incorrect because it is not a URI.
>>>
>>> Aside from that I don't understand why you think what you propose is
>>> easier to use or implement. (I agree that is uses fewer bytes, but that
>>> doesn't make it easier.)
>>>
>>>          Thanks,
>>>          Paul
>>>
>>>
>>>> Besides, if we disallow or ignore (or latest appearance overrides earlier) multiple appearance of alert-category then it will be more easier to implement.
>>>>
>>>>
>>>> I have another suggestion regarding the values of alert-category priority. If we make it a number like 0, 1, 10 anything may be between 00 to 99 or 0-9 to make it simple, then I think devices will have the provision to prioritize 2 calls/sessions (in case of call waiting or line busy) easily and devices will be able to implement specific logics for them.
>>>>
>>>> And if we can introduce another alert-category to guide the call/session handle behavoir according to service or priority for the devices e.g. force connect on busy, notify back when free, delivery report (read, delivered, not delivered etc) (as we are handing SIP sessions - the URNs should cover IM and short messages as well may be).
>>>>
>>>> Thanks&   Best Regards
>>>>
>>>>
>>>> JEWEL
>>>> Firoze M Zahidur Rahman
>>>>
>>>> _______________________________________________
>>>> salud mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/salud
>>>>
>>>
>>> _______________________________________________
>>> salud mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/salud
>>> _______________________________________________
>>> salud mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/salud
>>>
>>
>> _______________________________________________
>> salud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/salud
>> _______________________________________________
>> salud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/salud