Subject: [cuss] ABNF in UUI documents

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 20 Feb 2013 13:04:25 +0100

I make the ABNF more formal in the UUISDN document, and that requires a change to the UUI document.

Currently section 11 of draft-ietf-cuss-sip-uui-isdn-04 defines.

11.  Coding requirements

   This document defines "isdn-uui" as a new value of the User-to-User
   "purpose" header field parameter.

   This document defines "isdn-uui" as a new value of the User-to-User
   "content" header field parameter.  A content value of "isdn-uui"
   indicates that the contents have a first octet that is a protocol
   discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931]
   followed by uui-data that can be subject to a length limitation
   (before encoding or after decoding) that is generally 128 octets.

My question is whether this should define BNF to add this to the BNF of draft-ietf-cuss-sip-uui which is currently.

        UUI         = "User-to-User" HCOLON uui-value *(COMMA uui-value)
        uui-value   = uui-data *(SEMI uui-param)
        uui-data    = token / quoted-string
        uui-param   = pkg-param / cont-param / enc-param / generic-param
        pkg-param   = "purpose" EQUAL token
        cont-param  = "content" EQUAL token
        enc-param   = "encoding" EQUAL ("hex" / token)

If we did this I guess it would look something like:

        pkg-param   = "purpose" EQUAL "isdn-uui" / token
        cont-param  = "content" EQUAL "isdn-uui" / token

Originally I was thinking we could do something like

	pkg-param-value /= "isdn-uui"

but that would require an update to draft-ietf-cuss-sip-uui to do:

        pkg-param   = "purpose" EQUAL pkg-param-value
	  pkg-param-value = token

Can we make this change to the UUI document, and I'll then follow through with the UUI ISDN document?

regards

Keith

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 20 Feb 2013 14:43:03 +0000

Hi Keith,

your alternatives look a bit like a beauty competition. But we need to get the drafts stable and published the sooner the better.  I would thus have a slight preference for your first alternative that does not require updates of draft-ietf-cuss-sip-uui-isdn-04.

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext DRAGE, Keith (Keith)
Sent: Wednesday, February 20, 2013 1:04 PM
To: [email-masked]
Subject: [cuss] ABNF in UUI documents

11.  Coding requirements

regards

Keith
_______________________________________________
cuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cuss

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2013 11:31:39 -0500

Keith,

We are establishing a registry for purpose/package values.
IMO you should use that for "isdn-uui", rather than extending the syntax 
to include it.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 20 Feb 2013 17:56:31 +0100

These issues are orthogonal.

Placing a value in an IANA registry does not define it, all it does is make some attempt at stopping someone else from using it for a different purpose.

The normative definition is the base RFC. 

All I am doing is ensuring that the ABNF defines the values, rather than the text. If you extract the ABNF from both documents and combine them, then you can very strings against it.

What I am proposing is exactly what has been done for some, but not all, attribute values in SDP.

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: 20 February 2013 16:32
> To: [email-masked]
> Subject: Re: [cuss] ABNF in UUI documents
> 
> Keith,
> 
> > My question is whether this should define BNF to add this to the BNF of
> draft-ietf-cuss-sip-uui which is currently.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2013 12:21:50 -0500

> What I am proposing is exactly what has been done for some, but not all, attribute values in SDP.

First, let me be clear that I don't feel strongly about this one way or 
the other, so don't let my comments get in the way of getting this done.

I agree that in some cases we continue to update both ABNF and a 
registry. This *may* be viewed as helpful to readers. But it may also be 
deceptive and lull them into not checking the registry, which is a bad 
thing.

It also doesn't work in all cases. It only works when the rules for 
adding a new value require the production of a standards document.

The change you propose to the base document is harmless.

It is also possible to accomplish what you want without it, though the 
result is a little less pretty:

   pkg-param   /= "purpose" EQUAL "isdn-uui"

But IMO it is equally acceptable to not update the syntax at all. The 
value you are defining already conforms to "token".

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Wed, 20 Feb 2013 12:30:14 -0500

I agree with Paul. 

- Alan -

On Feb 20, 2013, at 11:31 AM, Paul Kyzivat <[email-masked]> wrote:

> IMO you should use that for "isdn-uui", rather than extending the syntax to include it.
> 
>    Thanks,
>    Paul
>

---

From: <[email-masked]>
Date: Thu, 21 Feb 2013 09:07:00 +0000

Hello,

In link with this topic, please also consider our last exchanges about the "purpose" parameter value ("isdn-uui" is the expected value but "isdn-interwork" shall also be interpreted when received): http://www.ietf.org/mail-archive/web/cuss/current/msg00445.html
Thank you for taking it into account in your update of UUI ISDN draft.

Celine Serrut-Valette
Orange Labs

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Paul Kyzivat
Envoyé : mercredi 20 février 2013 18:22
À : DRAGE, Keith (Keith)
Cc : [email-masked]
Objet : Re: [cuss] ABNF in UUI documents

> What I am proposing is exactly what has been done for some, but not all, attribute values in SDP.

First, let me be clear that I don't feel strongly about this one way or the other, so don't let my comments get in the way of getting this done.

I agree that in some cases we continue to update both ABNF and a registry. This *may* be viewed as helpful to readers. But it may also be deceptive and lull them into not checking the registry, which is a bad thing.

It also doesn't work in all cases. It only works when the rules for adding a new value require the production of a standards document.

It is also possible to accomplish what you want without it, though the result is a little less pretty:

But IMO it is equally acceptable to not update the syntax at all. The value you are defining already conforms to "token".

	Thanks,
	Paul

>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of Paul Kyzivat
>>> I make the ABNF more formal in the UUISDN document, and that 
>>> requires a
>> change to the UUI document.
>>>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.