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

[Ben Campbell <[e-mail]>]

> On Jan 9, 2019, at 8:58 AM, Alexey Melnikov <[e-mail]> wrote:
> 
> Hi Christer,
> I omitted the parts where we are in agreement.
> 
> On Wed, Jan 9, 2019, at 2:09 PM, Christer Holmberg wrote:
>> Hi Alexey,
>> 
>> Thank You for the review! Please see inline.
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
> 
> [snip]
> 
>>> 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.


>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>>> I am agreeing with Adam's DISCUSS.
>>> 
>>> In 8.2:
>>> 
>>>    pns-list        = pns *(COMMA pns)
>>> 
>>> My understanding is that COMMA (defined in RFC 3261) allows folding whitespace, in particular CRLF. Do you really want this in values? It is Ok if you do, I just wanted to double check.
>> 
>> In the SIP syntax we are less strict than in some other protocols when
>> it comes to folding whitespaces etc. The syntax above is very common in
>> SIP.
> 
> I was just surprised to see this inside a quoted strings. In email quoted strings typically either disallow spaces inside quoted strings or only allow SP, but not CRLF. But anyway, no change is needed if this was intended.
> 
> Best Regards,
> Alexey
>