Re: [dispatch] draft-montemurro-gsma-imei-urn-18

[Christer Holmberg <[e-mail]>]

Hi,



I am ok with the change, BUT keep in mind that it would prevent a future-gsma-specifier from having semicolon separated parameters.



One option would be to separate any possible parameters from future-gsma-specifier.



Something like:



future-gsma-specifier = future-specifier [ ";" future-params]

future-specifier = gsma-defined-nonempty-string

future-params = generic-param (...or, whatever syntax you want to use for parameters)





As an editorial comment, I would suggest to remove "-string" from gsma-defined-nonempty-string and software-version-string, as they are not quoted string values.





Regards,



Christer

________________________________
From: dispatch [[e-mail]] on behalf of Paul Kyzivat [[e-mail]]
Sent: Monday, 25 November, 2013 7:50 PM
To: Andrew Allen; Gonzalo Camarillo; [e-mail]
Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn-18

On 11/25/13 9:18 AM, Andrew Allen wrote:
> Paul
>
> I propose to change the ABNF to not allow ";" as an ext-imei character

OK. If that works for you it works for me.

        Thanks,
        Paul

> Andrew
>
> -----Original Message-----
> From: dispatch [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: Monday, November 25, 2013 10:51 AM
> To: Gonzalo Camarillo; [e-mail]
> Subject: Re: [dispatch] draft-montemurro-gsma-imei-urn-18
>
> On 11/25/13 7:18 AM, Gonzalo Camarillo wrote:
>> Hi Paul,
>>
>> thanks for the comment. Andrew will try and address it as an IETF LC
>> once the new IETF LC on the draft is over.
>
> OK. Note that this is more than editorial. To fix it, either the ";"
> must be excluded as an alternative, or quoting or escaping will need to be introduced.
>
>        Thanks,
>        Paul
>
>> Cheers,
>>
>> Gonzalo
>>
>> On 21/11/2013 9:15 PM, Paul Kyzivat wrote:
>>> One comment on this.
>>>
>>> I see the syntax has been extended. The extension has introduced an
>>> ambiguity:
>>>
>>>            imei-specifier = "imei:" ( imeival / ext-imei )
>>>                                             [ ";" sw-version-param ]
>>>                                             [ ";" imei-version-param ]
>>>            ext-imei = gsma-defined-nonempty-string ;GSMA defined
>>>                                                    ;and IETF
>>>                                                    ;consensus
>>>                                                    ;required ...
>>>            gsma-defined-nonempty-string = 1*gsma-urn-char
>>>            gsma-urn-char  = ALPHA / DIGIT
>>>                            / "-" / "." / "_" / "%"/":"/";"/"="
>>>
>>> ext-imei may contain a semicolon, and then following that a semicolon
>>> may also be used to initiate parameters.
>>>
>>>       Thanks,
>>>       Paul
>>>
>>> On 11/21/13 9:56 AM, Andrew Allen wrote:
>>>> Revised versions of draft-montemurro-gsma-imei-urn  and
>>>> draft-allen-dispatch-imei-urn-as-instanceid have been submitted.
>>>>
>>>> They can be found at:
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-montemurro-gsma-imei-urn-1
>>>> 8.txt
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-allen-dispatch-imei-urn-as
>>>> -instanceid-12.txt
>>>>
>>>>
>>>> along with the diffs from the previous versions at:
>>>>
>>>> http://www.ietf.org/rfcdiff?url2=draft-montemurro-gsma-imei-urn-18
>>>>
>>>> http://www.ietf.org/rfcdiff?url2=draft-allen-dispatch-imei-urn-as-in
>>>> stanceid-12
>>>>
>>>>
>>>> The main changes are as follows:
>>>>
>>>> draft-montemurro-gsma-imei-urn:
>>>>
>>>> The  ABNF has been updated to include the ability to extend the IMEI
>>>> value format in the future (as previously stated in the text) while
>>>> allowing a parser compliant with the current version of the
>>>> specification to still validate the URN.
>>>>
>>>> draft-allen-dispatch-imei-urn-as-instanceid
>>>>
>>>> The Emergency Access Transfer Function has been mentioned in the
>>>> Emergency Session transfer Use case.
>>>>
>>>> Various NITS have also been addressed.
>>>>
>>>> Please provide any comments as soon as possible. I understand that
>>>> the AD plans to make another IETF Last Call on these soon.
>>>>
>>>> Thanks
>>>>
>>>> Andrew
>>>>
>>>> --------------------------------------------------------------------
>>>> - This transmission (including any attachments) may contain
>>>> confidential information, privileged material (including material
>>>> protected by the solicitor-client or other applicable privileges),
>>>> or constitute non-public information. Any use of this information by
>>>> anyone other than the intended recipient is prohibited. If you have
>>>> received this transmission in error, please immediately reply to the
>>>> sender and delete this information from your system. Use,
>>>> dissemination, distribution, or reproduction of this transmission by
>>>> unintended recipients is not authorized and may be unlawful.
>>>>
>>>>
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>>
>>
>>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>
>

_______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch