Subject: [Megaco] DigitMapName in ASN.1

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 29 May 2002 18:52:14 -0400

Hi,

	ASN.1 profileName in ServiceChangeProfile has been changed in
draft-ietf-megaco-3015corr-01.txt from Name to string I guess since profile
name is just a string and does not have ASN.1 predefined tags.

	Should not ASN.1 DigitMapName currently defined as Name also
be changed to string which is currently defined as Name for the same reason?

Thanks
	Aleks

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 29 May 2002 20:25:57 -0400

ServiceChangeProfile was changed in ASN.1 to make it match the 
definition in the ABNF so that profiles names would come from a single 
namespace.  There is less reason for DigitMapName to have a universal 
definition across the two encodings.  In ASN.1 DigitMapNames are 
restricted to 2 octets as are package, property, event and signal names.

-- 

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked] 
Tel:732.949.5628   Fax:732.949.7016 
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 29 May 2002 20:25:57 -0400

--

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 29 May 2002 20:42:39 -0400

Hi,

         Exactly my question/point that I think DigitMapName should come from
a single name space as well.

I do not particularly agree that we should compare DigitMapNames with 
packages,
properties, etc., since DigitMapNames do not have predefined tags, like 
packages,
properties, etc. do. Thus I do not see strong reasons for creating unnecessary
restriction to have name space mapping for DigitMapNames .

Could you please clarify why "there is less reason for DigitMapName to have a
universal definition across the two encodings"?

Thanks
         Aleks

At 08:25 PM 5/29/2002, Terry L Anderson wrote:
>ServiceChangeProfile was changed in ASN.1 to make it match the definition 
>in the ABNF so that profiles names would come from a single 
>Tel:732.949.5628   Fax:732.949.7016 Lucent Technologies/INS/Voice Over IP 
>Access Networks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 29 May 2002 20:42:39 -0400

Hi,

Thanks
         Aleks

---

From: Christian Groves <[email-masked]>
Date: Thu, 30 May 2002 13:32:14 +1000

Hello Aleksandr,

Profile ID is globally unique for all gateway applications. DigitmapName are
particular to provisioning in a certain application. For a particular
implementation at a customer premises you'll use either text or binary and you
can provision your digitmapnames accordingly.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 30 May 2002 13:32:14 +1000

Hello Aleksandr,

Regards, Christian

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 30 May 2002 10:12:40 -0400

Package names are things that should be registered and may be shared 
between many MGs.  DigitMaps on the other hand are named at the time 
they are defined (like contexts, etc) and have only temporary meaning. 
 While one may use the same contents next time the name is used there is 
certainly no such assumption.  That is why they are much like signal and 
event names.  There is one difference, that digitmaps can be global and 
that is the only reason that I can understand a need for a longer more 
descriptive name in the binary encoding.  

Both binary and text MGs might register with the same MGC and if they 
have the same capabilities they might use the same profile and hence it 
is useful for them to use the same name.  Digitmaps on the otherhand 
only apply to a single MG and while both a binary and a text MG might be 
given the same digitmap I see less reason that MGC need use the same 
name in the messages to each.  The only case where this might be useful 
is where an MGC sends both binary and text messages (alternately) to the 
same MG and so want to set a digit map using text and then refer to it 
using binary.  While this is, I believe, legal I doubt many would want 
to do this and there are many other differences in naming (eg, 
terminationId, etc) that would have to be aliased when doing this.

But the main concern is that it would be a non-backward compatible 
change.  We do those only in the most serious needs and only when it is 
believed that it will impact existing implementations very little.  In 
this case it was believed that few if any packages had been publicly 
defined for binary encoding (most currently published packages specify 
text encoding) and that few were using private packages and so the 
impact would be modest.  Digitmaps are certainly much more widely used.

Aleksandr Ryabin wrote:

> properties, etc., since DigitMapNames do not have predefined tags, 
> like packages,
>> definition in the ABNF so that profiles names would come from a 
>> single namespace.  There is less reason for DigitMapName to have a 
>> universal definition across the two encodings.  In ASN.1 
>> DigitMapNames are restricted to 2 octets as are package, property, 
>> event and signal names.
>>
>> Aleksandr Ryabin wrote:
>>
>>> Hi,
>>>
>> Tel:732.949.5628   Fax:732.949.7016 Lucent Technologies/INS/Voice 
>> Over IP Access Networks

--

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 30 May 2002 10:34:58 -0400

Hi,

Non-backward compatible change of course is a winning reason here :).
Although I'm not sure it this is a good reason for v2 (and/or v3?), since 
it is
a different protocol (based on v1) and thus there should be no backward
compatibility issue.

I do understand that everything can be aliased and that will work now with no
problems. My concern was why create unnecessary mapping/aliasing for dual
(bin&text) MGCs by explicitly imposing restrictions in the protocol.
Is no big deal, but to simplify life for such MGCs it would be nice to have
as less mappings as possible.

Thanks
         Aleks

At 10:12 AM 5/30/2002, Terry L Anderson wrote:
>between many MGs.  DigitMaps on the other hand are named at the time they 
>are defined (like contexts, etc) and have only temporary meaning. While 
>one may use the same contents next time the name is used there is 
>Both binary and text MGs might register with the same MGC and if they have 
>the same capabilities they might use the same profile and hence it is 
>useful for them to use the same name.  Digitmaps on the otherhand only 
>apply to a single MG and while both a binary and a text MG might be given 
>the same digitmap I see less reason that MGC need use the same name in the 
>messages to each.  The only case where this might be useful is where an 
>MGC sends both binary and text messages (alternately) to the same MG and 
>so want to set a digit map using text and then refer to it using 
>binary.  While this is, I believe, legal I doubt many would want to do 
>this and there are many other differences in naming (eg, terminationId, 
>etc) that would have to be aliased when doing this.
>
>text encoding) and that few were using private packages and so the impact 
>would be modest.  Digitmaps are certainly much more widely used.
>
>Aleksandr Ryabin wrote:
>
>>Hi,
>>
>>>Tel:732.949.5628   Fax:732.949.7016 Lucent Technologies/INS/Voice Over 
>>>IP Access Networks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Thu, 30 May 2002 10:34:58 -0400

Hi,

Thanks
         Aleks

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 30 May 2002 10:12:40 -0400

--