Subject: RE: [Dime] application identifiers

From: "German Blanco \(E2/EEM\)" <[email-masked]>
Date: Fri, 3 Mar 2006 10:04:14 +0100

Hi,

I agree that the Vendor-Id AVP for applications does not make 
sense without a Vendor space for application ids.

I may get some shouts for this, but ... just in case someone 
else thinks that it would make sense to reopen the topic ...
in my humble personal opinion, a vendor space for applications,
and command codes makes the protocol only easier to extend.

German.

> -----Original Message-----
> From: Anders Kristensen [mailto:[email-masked]] 
> Sent: jueves, 02 de marzo de 2006 21:44
> To: Victor Fajardo
> Cc: [email-masked]
> Subject: Re: [Dime] application identifiers
> 
> 
> 
> Victor Fajardo wrote:
> > Hi,
> > 
> >> Anders,
> >>
> >> I am also confused based on seemingly confusing -at least to me- 
> >> statement/procedured in RFC3588.
> >>
> >> I guess/believe/think ApplicationId is globally unique based on:
> >> a)11.3 Application Identifiers
> >> It seems like ApplicationIds for all types of applications are 
> >> assigned from the same pool
> 
> Yes, that's clearly the case. There's a single IANA registry 
> for IDs of all types of apps.
> 
> >>
> >> b)Message header has ApplicationId but no other field to further 
> >> identify the application the message is belonging to.
> >>
> >> OTOH, espacially 2.7 seems to contradict the above view. 
> If a global 
> >> pool is used for ApplicationIds, I don't see the reason 
> why vendorId 
> >> is necessary to identify them uniquely.
> 
> Agreed.
> 
> >>  
> >>
> > I think Sec 2.7 has a bug. Only application id (which is/can be a 
> > vendor
> > id) is relevant for routing.
> > 
> > [snipet]
> > 
> >>>  - Messages belonging to IETF defined apps may have either an 
> >>> Auth-Application-Id or an Acct-Application-Id AVP. If it 
> does have 
> >>> one of those AVPs, the value will equal that of the 
> Application-ID 
> >>> field in the message header.
> >>>   
> >>
> >> [TOLGA]I am wondering, what is the use of those AVPs except when 
> >> advertising support during capability exchange procedure 
> -eem then, 
> >> why do we distinguish between different types of applications, 
> >> considering that ApplicationId are assigned from a global pool-? 
> >> Don't we have the ApplicationId already in the message 
> header -or am 
> >> I missing something fundamental-?
> >>  
> >>
> > We can add more to this confusion by looking at Sec 6.1 
> where an app 
> > id avp is mandatory for relayed messages. This implies that those 
> > avp's are used for routing instead of the id in the message header. 
> > OTOH, app-id definition in Sec 3 says that the app-id avp and the 
> > app-id in the header header must be the same
> 
> Would make sense if Vendor-Id was also needed for routing but 
> I agree that given that app IDs come out of a single flat 
> space apps are uniquely identified by the app id alone.
> 
> Anders
> 
> > but this is duplicated info as you
> > pointed out. For routing, only the id in the header is 
> relevant so you 
> > dont have to parse the entire message and look for an id.
> > 
> > victor
> > 
> > 
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dime
> > 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
> 

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