Re: [sipcore] Alexey Melnikov's Discuss on draft-ietf-sipcore-sip-push-21: (with DISCUSS and COMMENT)

[Christer Holmberg <[e-mail]>]

Hi,

>>>> 10.  pn-provider, pn-param and pn-prid URI Parameters for Apple Push
>>>>    Notification service
>>>> 
>>>>  The value of the pn-param URI parameter is a string that is 
>>>> composed  by two values, separated by a period (.): Team ID and 
>>>> Topic.  The  Team ID is provided by Apple and is unique to a development team.
>>>> 
>>>> I assume it doesn't contain any periods?
>>>> 
>>>>  The Topic consists of the Bundle ID, which uniquelly identifies an  
>>>> appliciation, and a service value that identifies a service  
>>>> associated with the application, separated by a period (.).  For 
>>>> VoIP  applications the service value is "voip".
>>>> 
>>>> How many periods are used in the value? If your example below is correct, can you clarify that Bundle ID itself contains periods?
>>>> 
>>>>  Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp.voip
>>> 
>>> The Bundle ID part of the Topic typically contains periods. The Team 
>>> ID, and the service part of the Topic, do not contain periods.
>>> 
>>> Note that the Topic is actually created by Apple, and I don't even 
>>> know whether the Apple PNS needs to separate the Bundle ID part from 
>>> the service part. And, as far as I know, we don't need to separate 
>>> the parts in our proxy implementation. We do separate the Team ID 
>>> from the Topic, but we know the first period is the separator (as the 
>>> Team Id does not contain periods).
>> 
>> I think you either need to clarify that the Bundle ID can contain periods (so that if somebody wants to parse a particular pn-param 
>> value, they know to search for the last "." (*)) or you should avoid talking about internal structure altogether. Your text is sort of in between.
>> 
>> (*) - it might not be sensible to need to parse internal structure of the value. But I can't decide one way or another without investigating Apple API for this, which I haven't done.
>> 
>
> Given that we don’t have change control over the parameters for Apple (or any other proprietary PNS), I’d be very careful about expectations to parse 
> internal structure. These structures could change at any time.

Sure. But, if it changes in a way that is not compatible with the current text/syntax, then one would need to register a new pn-provider value.

Regards,

Christer