Subject: RE: [Sip] WGLC for Informational Draft on Media Authorization

From: "Mark Watson"<[email-masked]>
Date: Mon, 25 Mar 2002 14:24:37 -0000

All,

A very late but very small, and perhaps important, comment: the header
carries a hex string which contains a Policy Element as defined in RFC2750,
including length and P-Type. Should it be able to carry more than one Policy
Element ? RSVP allows you to include more than one, and since the Policy
Elements can be of different types, the flexibility to include more than one
could be of value.

Sinec the token in this header is just a hex string, including length and
type bytes, then the syntax can remain the same, and the procedure at the
UAs (copy the data into the appropriate place in the RSVP POLICY-DATA
object) remains the same.

Regards...Mark

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: 10 March 2002 22:09
> To: [email-masked]
> Cc: Rohan Mahy; [email-masked]; [email-masked];
> [email-masked]; Flemming Andreasen
> Subject: [Sip] WGLC for Informational Draft on Media Authorization
> 
> 
> We'd like to open discussion for a working group lst call on:
> 
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-call-auth-04.txt
> 
> Please note that this is not a standards-track draft. It 
> defines a p-class
> header used for interworking with a restricted set of QoS 
> policy managers
> potentially used in some cable and wirless networks, It is 
> also part of the
> "Bundle 2" set deemed critical by 3GPP.
> 
> We plan to conclude WGLC on or about 25 March 2002 and 
> advance to IETF last
> call as soon as possible thereafter.
> 
> --
> Dean Willis
> SIP WG co-chair.
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 25 Mar 2002 18:07:19 -0500

Mark Watson wrote:

> carries a hex string which contains a Policy Element as defined in
> RFC2750, including length and P-Type. Should it be able to carry more
> than one Policy Element ?

Yes.

> RSVP allows you to include more than one, and since the Policy
> Elements can be of different types, the flexibility to include more
> than one could be of value.
>
> Sinec the token in this header is just a hex string, including length
> and type bytes, then the syntax can remain the same, and the procedure
> at the UAs (copy the data into the appropriate place in the RSVP
> POLICY-DATA object) remains the same.
>

The text already talks about having multiple Authorization Tokens,
however this was added fairly late, and I forgot to bis-align the
grammar. Updated grammar would be:

        P-Media-Authorization           = "P-Media-Authorization" HCOLON
P-Media-Authorization-Token
                                                                *(COMMA
P-Media-Authorization-Token)

        P-Media-Authorization-Token     = 1*HEXDIG

Unless I hear any objections, I will go ahead and make this change.

Thanks for the comment

            Flemming

--
Flemming Andreasen
Cisco Systems