Subject: Re: [Dime] Problem with Origin- & Destination-Realm AVPs in RFC3588bis

From: Victor Fajardo <[email-masked]>
Date: Thu, 05 Mar 2009 11:08:02 -0500

Hi Fortune,
> Hi Victor,
>
> I am fine with the proposal. Just to make sure one thing, do we need to
> specify it is a realm or a FQDN when defining a AVP of type DiameterIdentiy?
>   
I would think so.
regards,
victor

> Best Regards,
> Fortune
>
>
> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]] 
> Sent: Thursday, March 05, 2009 10:31 PM
> To: Fortune HUANG
> Cc: 'jouni korhonen'; [email-masked]; [email-masked]
> Subject: Re: [Dime] Problem with Origin- & Destination-Realm AVPs in
> RFC3588bis
>
> Hi Fortune/Jouni/Lionel/Glenn,
>
> So, ca we proceed with Lionel's proposal ? Any other issues with it ?
>
> regards,
> victor
>
>   
>> Hi Jouni,
>>
>> Thank you very much for your correction and telling me the right place for
>> FQDN. 
>>
>> Best Regards,
>> Fortune
>>
>> -----Original Message-----
>> From: jouni korhonen [mailto:[email-masked]] 
>> Sent: Thursday, March 05, 2009 5:43 PM
>> To: Fortune HUANG
>> Cc: 'Victor Fajardo'; [email-masked]; [email-masked]
>> Subject: Re: [Dime] Problem with Origin- & Destination-Realm AVPs in
>> RFC3588bis
>>
>>
>> Hi Fortune,
>>
>>
>> On Mar 5, 2009, at 4:46 AM, Fortune HUANG wrote:
>>
>> [snip]
>>
>>
>>   
>>     
>>> My conclusion after comparing the grammars of the three RFCs:
>>> 1) According to the above RFC4282 grammar, "2.a " is a valid realm.
>>>     
>>>       
>> Correct.
>>
>>   
>>     
>>> 2) According to the above RFC4566 grammar, "2.a " is not a valid  
>>> FQDN since
>>> it has only 3 characters (not 4 or more).
>>>     
>>>       
>> First, RFC4566 ABNF is not in a role for defining FQDN.. it is an ABNF  
>> for SDP grammar. So if the SDP grammar ABNF is wrong, it is not the  
>> problem of original FQDN ABNF. Besides, using "2.a" as an example is  
>> misleading. There is no root zones that are one character long (see  
>> ICP-1, RFC1591). The shortest root zone is two characters, which would  
>> e.g. be "2.ac" and this is correct according to the ABNF in RFC4566.  
>> The RFC1035 BNF would allow one character root zones, however, those  
>> just do not exist in Internet DNS.
>>
>>   
>>     
>>> 3) According to the above RFC1035 grammar, "2.a" is not a valid  
>>> domain since
>>> it doesn't start with a letter (but a digit).
>>>     
>>>       
>>   updates RFC1035 and relaxes the issue with a digit being the  
>> first character.
>>
>>
>>   
>>     
>>> If one could prove that the grammar of realm is the same as the  
>>> grammar of
>>> FQDN,  then, RFC4282, RFC1035 and RFC4566 would be proven inconsistent
>>> according.
>>>     
>>>       
>> So far, no problems with cases 2) and 3). Regarding the case 1) few  
>> notes. RFC3588bis section 1.3. states that "NAI realm names are  
>> required to be unique, and are piggybacked on the administration of  
>> the DNS namespace." This basically means one loses its rights for  
>> "creative" realm names when used with Diameter. In DNS, one character  
>> root zones do not exist, thus "2.a" is not legal within Diameter scope.
>>
>>   
>>     
>>> However, I am not sure if I have found the right place where the  
>>> strict
>>> grammar of FQDN is defined. Please tell me if you know.
>>> But RFC4566 and RFC1035 were the materials my comment in the  
>>> previous email
>>> was based on.
>>>     
>>>       
>> Although this stuff is spread a bit around and topped with de-facto  
>> assumptions, I think there is no issue.
>>
>> Cheers,
>> 	Jouni
>>
>>
>>
>>
>>   
>>     
>>> Best Regards,
>>> Fortune
>>>
>>> -----Original Message-----
>>> From: Victor Fajardo [mailto:[email-masked]]
>>> Sent: Thursday, March 05, 2009 6:02 AM
>>> To: [email-masked]
>>> Cc: [email-masked]; [email-masked]; [email-masked]
>>> Subject: Re: [Dime] Problem with Origin- & Destination-Realm AVPs in
>>> RFC3588bis
>>>
>>> Hi Fortune,
>>>     
>>>       
>>>> I'm not sure to understand but I might have missed something.
>>>>       
>>>>         
>>>>> From a syntax point of view, what is the difference between a FQDN  
>>>>> and a
>>>>>         
>>>>>           
>>> realm?
>>>     
>>>       
>>>> What would be the "potential" impacts to say that the  
>>>> DiameterIdentity can
>>>>       
>>>>         
>>> be a FQDN or a realm?
>>>     
>>> I have the same question as Lionel. Syntactically, FQDN and realm  
>>> are the
>>> same from the parsers point of view. The difference is in semantics  
>>> which is
>>> already specified by the AVP having that type.
>>>
>>> regards,
>>> victor
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dime
>>>     
>>>       
>>
>>
>>
>>   
>>     
>
>
>
>
>
>

---

From: Fortune HUANG <[email-masked]>
Date: Fri, 06 Mar 2009 08:35:40 +0800

Hi Victor, 

Then it would be perfect for me.

Best Regards,
Fortune

-----Original Message-----
From: Victor Fajardo [mailto:[email-masked]] 
Sent: Friday, March 06, 2009 12:08 AM
To: Fortune HUANG
Cc: 'jouni korhonen'; [email-masked]; [email-masked]
Subject: Re: [Dime] Problem with Origin- & Destination-Realm AVPs in
RFC3588bis

Hi Fortune,
> Hi Victor,
>
> I am fine with the proposal. Just to make sure one thing, do we need 
> to specify it is a realm or a FQDN when defining a AVP of type
DiameterIdentiy?
I would think so.
regards,
victor

>> Thank you very much for your correction and telling me the right 
>> place for FQDN.
>>
>> Best Regards,
>> Fortune
>>
>>> FQDN since it has only 3 characters (not 4 or more).
>>>     
>>>       
>> First, RFC4566 ABNF is not in a role for defining FQDN.. it is an 
>> ABNF for SDP grammar. So if the SDP grammar ABNF is wrong, it is not 
>> the problem of original FQDN ABNF. Besides, using "2.a" as an example 
>> is misleading. There is no root zones that are one character long 
>> (see ICP-1, RFC1591). The shortest root zone is two characters, which 
>> would e.g. be "2.ac" and this is correct according to the ABNF in
RFC4566.
>>> domain since it doesn't start with a letter (but a digit).
>>>     
>>>       
>>   updates RFC1035 and relaxes the issue with a digit being the first 
>> character.
>>
>>
>>   
>>     
>>> grammar of FQDN,  then, RFC4282, RFC1035 and RFC4566 would be proven 
>>> inconsistent according.
>>>     
>>>       
>>> strict grammar of FQDN is defined. Please tell me if you know.
>>> previous email was based on.
>>>     
>>>       
>>> are the same from the parsers point of view. The difference is in 
>>> semantics which is already specified by the AVP having that type.
>>>
>>> regards,
>>> victor
>>>