Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-02.txt

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Wed, 27 Feb 2002 09:19:37 +0100

> Hi, 
Hi,

(comments inline)

>I have a question/comment reqarding the I-D in e-mail below. 
> Section 2.1 states that "where safe and byte-string are as 
> defined in SDP [SDP]" regarding usage of the new SDP attributes:
>
> keymgmt-data   = "keymgmt-data: " byte-string 
> key-extra-auth = "keymgmt-auth:" byte-string 
> In RFC 2327 "SDP: Session Description Protocol", 
> "byte-string" is defined as: 
>
> text =                   byte-string 
>                         ;default is to interpret this as IS0-10646 UTF8 
>                         ;ISO 8859-1 requires a "a=charset:ISO-8859-1" 
>                         ;session-level attribute to be used 
>
Almost ;-) 
   byte-string =         1*(0x01..0x09|0x0b|0x0c|0x0e..0xff)
                         ;any byte except NUL, CR or LF
anyway...

> Since this data can be encrypted, shouldn't the parameter be 
> "base64 encoded data" instead (perhaps I am missing something)? 

I agree that this will be the best way to do it in most solutions. 
But as this is a framework, I don't think it is good to restrict 
the encoding of the field too much. Therefore, the encoding of the 
field is uniquely defined by the key management protocol used 
(I guess we will need to clarify this). E.g. if MIKEY is used, then 
the "keymgmt-data" field will be base64 encoded as it is stated 
that in MIKEY.

> See Section 6.0 of <draft-ietf-msec-mikey-00.txt> "MIKEY: 
> Multimedia Internet KEYing" where a specific example is given 
> (I cut and paste from that I-D below):
>     a=keymgmt-data:<base64 encoded data> 
> Also, I'm not sure about the usage of "safe" in the SDPbis I-D 
> (see <draft-ietf-mmusic-sdp-new-05.txt> "SDP" Session Description 
> Protocol". 
>
That's a good one. It just disapeared :-)  

Thanks,
Fredrik

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Wed, 27 Feb 2002 18:18:23 -0500

--> "Fredrik Lindholm (ERA)" writes:
...
>That's a good one. It just disapeared :-)  

It disappeared because it was inconsistent. RFC 2327 says (section 6):

	SDP session descriptions are entirely textual using the ISO 10646
	character set in UTF-8 encoding. SDP field names and attributes
	names use only the US-ASCII subset of UTF-8, but textual fields 
	and attribute values may use the full ISO 10646 character set.   

and

	Text records such as the session name and information are bytes
	strings which may contain any byte with the exceptions of 0x00
	(Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return).  The
	sequence CRLF (0x0d0a) is used to end a record, although parsers
	should be tolerant and also accept records terminated with a single
	newline character.  By default these byte strings contain ISO-10646
	characters in UTF-8 encoding, but this default may be changed using
	the `charset' attribute.

and in o= restricts the username field to not containing spaces (i.e. the
username can be any UTF-8 character except NUL, CR, LF and space). This
conflicted with the definition of "safe" in the ABNF, which was much more
restrictive. The new ABNF makes username a non-ws-string, which actually
matches the text.

Colin